devopsy.kinsta.cloud

Tag: software developers

Developer Resistance to AI Isn’t Fear – It is Identity

Developers are often assumed to resist AI because they fear it will take their job, that using it means training their own replacement. That is not quite right. What is happening is that AI has changed, permanently, what the job of a developer is. And not every developer is, or has to be, okay with that.

A 2024 peer-reviewed study backs this up: developers’ concerns centre less on job loss and more on how AI reshapes the work itself. The market data agrees. In 2025, 84 percent of developers were using or planning to use AI coding tools, yet only 33 percent trusted the code those tools produce, according to the same survey. Adoption is rising. Trust is falling. That gap is the real signal, and it has nothing to do with job security.

Traditional coding is hands-on. Developers solve problems, shape architecture, write code, debug, and make technical decisions directly. That is the part most engineers enjoy. AI-assisted coding moves the developer up a level: instructing, reviewing, correcting, and orchestrating AI agents rather than writing the code themselves. That is not necessarily a downgrade, but it is a different job, and many programmers did not become programmers because they wanted to manage other programmers, even artificial ones.

The psychological mechanism behind the resistance is similar to what happens when you ask one coder to supervise another. It requires a different type of effort. Each developer has their own preferred work style and may feel that writing the solution themselves would take less effort than reviewing, explaining, and refining someone else’s work. AI creates a similar dynamic. The developer now has to define tasks clearly, supervise execution, validate the output, accept accountability for code they did not personally write, and operate at a higher level of abstraction. For some people this is exciting. For others, it removes the part of programming that gives them energy.

AI is not like other programming skills, either. Learning a new programming language, such as moving from Java to Python, is still recognisably “coding.” It preserves the same underlying craft. But AI alters the developer’s workflow and what their job actually “is.” That is why some engineers who are perfectly happy to learn new technologies may still resist AI. They are not resisting change in general. They are resisting a move from maker to orchestrator.

This means companies should be careful not to frame AI adoption only as an efficiency initiative. Saying “AI will save you time” may not address the real concern. The issue is not only productivity, but also professional motivation, ownership, accountability, and identity. A better framing would be that AI does not simply make coders faster; it changes where human creativity sits in the process. The opportunity is to help engineers move from writing every line of code to designing better systems, asking better questions, validating better solutions, and making higher-level product and architecture decisions.

But this transition needs to be managed deliberately. Not everyone will naturally enjoy it, and not everyone will be good at it immediately.

It is also why the “1000x developer” – the top 1-2% of hyper-skilled engineers – is so often misdiagnosed as a skill category rather than a character trait. What separates them is not technical range. It is the willingness to let go of hands-on coding and be measured on outcomes, whether what they are managing is a group of people or a group of AI agents.

August 14, 2026
IronWorm Malware Shares Shai-Hulud Traits, Takes Threat to ‘Next Level’

Open source software developers continue to come under attack, with the latest threat being a custom malware that shares many of the attributes of the notorious Shai-Hulud self-propagating worm but comes with functions that make it more difficult for defenders to detect and to reverse engineer.

Dubbed “IronWorm,” the infostealer is built in the Rust programming language and targets developers – both software as well as cryptocurrency and Web3 – through malicious npm packages, according to researchers with JFrog Security. It self-replicates across the software supply chain by stealing credentials and uploading GitHub commits, and then automatically publishing new packages to the npm registry.

“The fact that every npm package belonging to the compromised account was republished with a malicious version strongly suggested that the malware had an automated way to publish packages on behalf of its victims,” the researchers wrote in a report. “The code confirmed it.”

It steals a broad range of developer secrets, including cloud credentials, npm publishing tokens, and API and SSH keys. It looks for them in just about every major platform that developers use, from cloud providers and object storage to databases, CI/CD systems, Kubernetes, and messaging platforms. It also targets AI and machine learning API keys from players like OpenAI, Google Gemini, Anthropic, Mistral, and Groq.

Two Payloads

IronWorm uses a Tor-based command-and-control (C2) structure for communications and has two payloads for different repository structures, with each payload using a different identity to blend in.

“If the repository shipped a package – npm, PyPI, Cargo, Conan, or vcpkg (C++) – the malware took a more direct route: it dropped a binary into the project and modified the build system to execute it,” the researchers wrote, noting that this was what they saw in the wild. “If the repository already had GitHub Actions workflows, the malware had a second, nastier option: it did not add a new file, but replaced an existing one – swapping a real workflow for a secret-exfiltration job.”

They also pointed to the malware hiding behind an eBPF kernel rootkit, calling it a “standout feature” of the threat.

eBPF Used for Good and Bad

“On modern Linux systems, eBPF gives code unusually deep visibility into system activity and, in the wrong hands, a place to hide,” the researchers wrote. “The same technology used for observability and security tooling can also be abused to intercept events, manipulate what monitoring tools see, and conceal the malware’s own operations from defenders.”

They uncovered IronWorm while reviewing npm packages published by a particular account that was tied to a GitHub organization. What piqued their interest was that every one of the account’s packages had been republished inside a particular narrow window, with each new version shipping a native binary that ran from an install hook.

“That was enough to make us look closer,” they wrote, adding that the “packages were nearly identical.”

Similar But Different

The threat group TeamPCP has used Shai-Hulud for several months in campaigns targeting developers and the software supply chain. Last month, the bad actors put the worm’s source code into a GitHub repository, giving bad actors the ability to create their own variants, with multiple such clones – like the Miasma malware – being found in the wild, according to Datadog analysts.

However, while they didn’t say IronWorm was such a clone, the JFrog researchers noted some similarities to Shai-Hulud. That said, they wrote that what they were looking at was a “custom, carefully built implant from an operation with its own infrastructure and the patience to use it quietly.”

Like Shai-Hulud, it compromises developers, steals credentials, and uses trusted supply-chain workflows to spread. It also uses the same commit names as Shai-Hulud.

“But it takes the same concept to the next level,” they added. “It makes defenders’ lives harder on several fronts at once: Rust code that is painful to reverse engineer, string [encryption with a unique key at every call site] obfuscation, a modified UPX packer, Tor-based C2, an eBPF rootkit.”

A Work in Progress

They also saw that the malware’s compiler left behind the source code, and added that they found 57 back-dated malicious commits across nine organizations and saw that the operator hardcoded their own crypto wallet’s recovery phrase into the malware so it would steal from them.

Researchers with Ox Security wrote that IronWorm infected 36 unique packages, and that while those affected generated a combined 32,177 monthly downloads, IronWorm was mitigated before the infection spread too widely.

Despite what they found, the JFrog researchers wrote that IronWorm “still looks like a work in progress. Some parts are carefully engineered, but others are surprisingly careless. The BPF object still contains debug metadata and recoverable source lines, and the operator even hardcoded a wallet recovery phrase into the malware’s skip list. These mistakes gave us a rare look into how the implant works. In other words, this may not be the final form of the campaign, it may be the rehearsal.”

June 5, 2026
N. Korean Famous Chollima Hackers Use Malicious npm Packages to Steal Data

A group of more than two dozen malicious npm packages used to steal secrets and credentials from software developers has all the hallmarks – from infrastructure to operations – of Famous Chollima, the North Korean nation-state actor linked to the ongoing high-profile Contagious Interview scam.

Threat researchers with Socket and Kieran Miyamoto of the DPRK Research blog detected the campaign – dubbed “StegaBin” due to its use of Pastebin steganography, a communication technique used by attackers to hide malicious information – late last month, noting that the malicious packages were added to the npm repositories over two days in the last week of February.

“The packages use a Pastebin-based dead-drop resolver that hides C2 infrastructure inside seemingly benign text using character-level steganography,” Socket threat researchers Philipp Burckhardt and Peter van der Zee wrote in a report, noting that the infrastructure for the campaign was hosted on 31 Vercel deployments. “The infection chain retrieves platform-specific shell payloads that ultimately install a Remote Access Trojan (RAT) and automatically deploys a nine-module infostealer toolkit.”

The modules are used to directly target developer environments, such as VSCode configuration, SSH keys, git repositories, browser credential stores, clipboard data, and locally stored secrets, Burckhardt and van der Zee wrote.

Tracking Famous Chollima

Socket researchers over the past year have tracked Famous Chollima – suspected of being a subset of the notorious Lazarus Group that is run by the Democratic People’s Republic of Korea (DPRK) – and its use of malicious npm packages as part of its ever-evolving Contagious Interview campaign, which has been going on for three years and targets developers with fake job interviews and test projects.

In StegaBin, the 26 repositories are typosquats of popular npm libraries – they’re given names that closely resemble and can be mistaken for legitimate repositories – and the “-lint” suffix in eight of the 26 make them appear to be developer tools. Fifteen of the accounts are clustered into three personas – christopher.smith.*47, andrew.*walker*, and joni* — with the other 11 on their own.

The packages each include an install script, which contains both decoy functions to camouflage its presence and the real payload that is designed to blend in as a copy of the legitimate script.

Typosquatting, Obfuscation

The researchers pointed out that the bad actors make a point of declaring the legitimate packages that they’re typosquatting as a dependency, a move that likely has two purposes. The first is to add the air of legitimacy to the structure of the package; the second to delay discovery.

“By proxying the legitimate package into the environment, a victim’s project might still compile and run normally after an accidental installation,” Burckhardt and van der Zee wrote. “Because the application doesn’t immediately break, the developer remains unaware of the mistake while the malicious install script executes the infection chain in the background.”

The malicious payload is heavily obfuscated through RC4 string encryption, array rotation, self-defending anti-debug, and control flow flattening, they added. The core logic includes three hardcoded Pastebin URLs that are used as a fallback chain, and the pastes contain what seems to be a benign essay about computer science.

RATS, Stealers, and Scanners

However, the payload can decode the text steganography, with the decoder scanning the text to find specific characters that together create a number of names for command-and-control (C2) domains.

From there, the malware pulls in platform-specific payloads for a range of operating environments, such as Linux, Windows, and macOS. The shell script used for this also pulls in a remote access trojan (RAT).

Once connected, the C2 deploys a nine-module infostealer toolkit, with modules containing a keylogger, mouse tracker, and clipboard stealer, a Python-based browser stealer, another obfuscated stealer, a TruffleHog scanner, and StegaBin loader. Other modules are used to exfiltrate cryptocurrency, steal information, and establish VSCode persistence.

The modules provide significant capabilities. The keylogger-mouse tracker-clipboard stealer also includes active window title tracking, encrypted local storage, and periodic exfiltration, while crypto wallet stealer targets five browsers – Chrome, Brave, Firefox, Opera, and Microsoft Edge – across all three operating systems.

There are two RATs that exfiltrate files, while another module can collect all files from a SSH directory and reads all stored Git credentials.

Similar to Contagious Interview

StegaBin is essentially another iteration of the techniques used by Famous Chollima in the Contagious Interview campaign. However, there are differences.

“While previous waves of the Contagious Interview campaign relied on relatively straightforward malicious scripts and Bitbucket-hosted payloads, this latest iteration demonstrates a concerted effort to bypass both automated detection and human review,” Burckhardt and van der Zee wrote. “The use of character-level steganography on Pastebin and multi-stage Vercel routing point to an adversary that is refining its evasion techniques and attempting to make its operations more resilient.”

They also pointed to the presence of Hardhat, an Ethereum development environment, in the infection chain, an indication that “cryptocurrency and Web3 developers remain the primary targets of this North Korean cluster.”

“Given the sophistication of this attack and its direct targeting of the developer workspace, organizations must remain vigilant,” they wrote. “Developers should carefully review dependencies and not install untrusted packages blindly.”

March 3, 2026
6 Essential Components of a Successful Security ‘Rewards Program’ for Software Developers

In real life, frequent flyer programs reward travelers with various benefits based on their travel habits. As you accumulate miles and achieve higher status levels with a particular airline, you gain access to perks such as fast-track security, priority boarding, complimentary upgrades and exclusive lounges. These incentives not only elevate individuals’ status but also make their travel more efficient and faster. The software development industry could use something like a ‘frequent flyer status’ system — especially when it comes to ensuring a ‘security first’ mindset among developers. Without such a system, it is difficult, if not impossible, for organizations and their developer teams to assess their security proficiency and compare their competencies with peers. According to our research, such assessments are needed more than ever, as nearly two-thirds of developers report they find it challenging to write code free from vulnerabilities, and about half admit they leave vulnerabilities in their code.

To address these issues, development teams are undergoing training and earning mandated certificates to boost their security skills and practices. However, these approaches — mainly when conducted piecemeal — remain limited in terms of providing a comprehensive view of how participants’ proficiency progress aligns with organizational security objectives.

Whether teams opt for on-the-job collaborative training opportunities or interactive, agile learning sessions, they would substantially benefit from standardized developer benchmarking for success. Such benchmarking could lead to a ‘trust score’ that, much like rewards programs, would provide incentives to developers for their security achievements and offer clear pathways for improvement.

So, what criteria should organizations focus on when coming up with impactful industry benchmarking and an informative, actionable trust score? Here are six essential assessment areas of this ‘frequent flyer’ approach:

Skill proficiency: Leverage data to evaluate team members’ understanding of safe coding principles. Ask: Are they up-to-speed on the various languages and trends that affect the protection of products from vulnerabilities? Are they deploying the right tools and methodologies to support a proactive, ‘security-first’ culture?

Industry frameworks: It is essential to gauge team members’ adherence to industry-respected security frameworks. This includes the OWASP Top 10, which helps developers stay updated on critical risks; and ‘“Secure–by-Design’ principles – a necessary step toward ensuring more consistent secure software development lifecycles. This past May, over 100 hundred technology vendors signed a secure-by-design pledge, committing to implementing these principles to mitigate potential flaws in software that could arise when the software is in the hands of end users. Each week, we continue to see more vendors sign the pledge, and over time, their developers will be further empowered to verify their secure coding skills and ensure they are doing their part.

Continuous training and skills improvement: Organizations should consistently invest in learning opportunities to help teams continuously improve, along with metrics that measure members’ commitment to upskilling their capacity for protection.

Team collaboration/efficiency/performance: Benchmarking and trust scores are necessary to establish a baseline for measuring the true impact and effectiveness of learning programs and the overall security posture of developer teams. More importantly, a benchmark provides an appropriate jumping-off point for deeper conversations and collaborations between development, engineering and security teams, helping to close potential security gaps and find solutions in the software supply chain.

In-production performance measurement: To effectively gauge developers’ security capabilities, evaluations should extend beyond training and skill assessments to analyze their behavior during code production. With these benchmarks in place, consider the following questions: How many mistakes are developers still making? Are they learning from their mistakes and fixing security bugs? Are they coaching peers to develop codes securely? Do they conduct peer review pull reviews for security flaws?

Competitive analysis: This aspect will answer the overarching question, ‘How do we compare to other organizations in our industry? Are certain trust scores lagging our competitors, indicating a need for immediate attention and training?’

We understand that developer teams are under pressure to produce better code faster. As a result, they may view security as a barrier to innovation, leading them to take shortcuts or ignore vulnerabilities entirely. To evaluate the current security culture and the mentorship provided to developers, it is important to assess not only whether they are coaching their peers but also the depth and effectiveness of their guidance and how it impacts their own security practices.

By establishing a baseline to verify developers’ secure coding skills and measurement, security teams will get a clear sense of how well they are producing secure code from the beginning. They will gain a greater appreciation for how ‘security-first’ contributes to more robust products and will even save time in the long haul since they wouldn’t have to ‘work backward’ late in the process to fix issues.

In addition, they will recognize that benchmarking/trust score-driven continuous improvement makes them more capable and marketable on a professional level, leading to more intriguing job opportunities and promotions. In other words, this is a ‘win-win’ initiative for the organization, the individual developer and overall software safety.

October 23, 2024
The Rise of Coding Assistants: Supercharging Developer Productivity

The rapid advancements in large language model (LLM) coding assistants have sparked debates about the future of coding, with some even predicting doomsday for coders. But in Heroku, we see a different trend — LLMs are democratizing coding, so much so that we are beginning to see a wave of novice software developers jumping into the business.

This influx of programmers presents some unique challenges for AI assistants. Experienced developers, for example, are better equipped to notice when an assistant is leading them down the wrong coding path whereas junior developers might fail to notice something is amiss.

Additionally, an LLM’s code quality can vary greatly depending on language choice and application area. Utilizing the assistant to write a Python or Java backend is usually not a problem; however, asking it to write Zig or a newer language like Mojo can end in disappointment. For example, when asked how to install Python packages, an assistant will direct a user to use pip or conda as those are the most common tools in their training data. Meanwhile, developers are off late preferring Poetry for dependency and management packaging in Python; AI tools do not ideally use or consider that unless a developer asks for it specifically.

Outdated information can also be a problem, especially when languages and frameworks try to phase out old features or when libraries that were once in use contain security vulnerabilities that haven’t been fixed yet.

Harnessing Data to Supercharge LLMs for Developers

So, how do we help assistants (and by extension, developers) avoid such snags? Firstly, it is critical to have current data informing LLMs. While larger organizations can use their existing codebases and operational data to partially address this issue, complete access to comprehensive, up-to-date datasets is unavailable. In fact, 62% of global workers say training AI on out-of-date data breaks their trust in the tool. Similarly, companies lack enough relevant data when introducing new languages or trying to change the status quo.

The necessary data curation can be addressed in a collaborative community-focused manner following patterns established by open-source projects. This does not mean we must agree on a single set of best practices. On the contrary, it makes sense for existing language, tooling and framework communities to each produce a dataset or Framework Knowledge Base (FKB) that is curated specifically for their area of interest.

The optimal method for augmenting existing models with these FKBs is not clear. But that should not prevent anyone from producing them. Whether it is wholly pushed into the context window, accessed via retrieval augmented generation (RAG), or used for fine-tuning, having timely, accurate and relevant data that remains consistent is the best first step.

Framework Knowledge Bases for LLMs

How does a user interact with these FKBs? Imagine a menu for users to select from when they activate their coding assistant. The user would choose one or more FKBs tailored to a particular goal. Each FKB would include a getting-started template for the assistant to work from. In addition to the template, the FKB would include code samples, best-practice guides and recommended libraries.

To maximize success, the datasets would be created and curated by language and framework experts. However, every journey starts with a single step, or in this case, a person with the capacity and willingness to forge ahead and make the first FKB. There are a few questions this pioneer would need to answer:

1. What license should the FKB use? Ideally, these datasets would be available to everyone. To ensure the broadest usage, one must pick something extremely permissive, such as Unlicense or CC0.

2. Where must the FKB be stored? Ideally, this is a place where people can collaborate on datasets and have an easy method to modify the dataset if they disagree on some choices. For example, a GitHub repository is a good fit because the template can be used directly and allows for stars, pull requests and forks. A Huggingface dataset could also work. Another idea is to include an ai-hints.json file directly in an existing repository.

3. What test data should be included for LLMs? In future, one of the challenges would be evaluating an LLM’s performance using a dataset. These evaluations would require test data as well as training data. To address this, the FKB must contain domain-specific examples that can be used as a test set to evaluate the performance of LLMs.

Coding Assistants Become Extraordinary Tools

Fostering a collaborative, community-driven approach to curating and sharing knowledge can help ensure that coding assistants become extraordinary tools that empower developers of all skill levels. This journey begins with the collective effort of the tech community to create and refine datasets that keep pace with the ever-changing landscape of programming languages and tools. Together we can build a future where coding assistants simplify coding and inspire innovation across the global developer ecosystem.

June 19, 2024
Pilot or Telephone Operator? Forecasts of Software Developer Demise Are Absurd

Stability AI CEO Emad Mostaque recently grabbed headlines with his audacious prediction that “there [will be] no programmers in five years.” While such statements make great social media clickbait, they don’t accurately reflect the reality of creativity’s role in complex software development. Yes, AI will profoundly change the software engineering profession, but those changes will mostly enable inventive and capable developers to reach new heights of innovation. Software development is already being transformed by generative AI. Microsoft’s GitHub Copilot has more than one million paying customers. Some researchers forecast that between 50% and 80% of software engineering job descriptions will involve generative AI within a few years.

For the foreseeable future, generative AI’s principle value will be automating the mundane tasks that take up so much developer time. Copilots will likely replace many frameworks and code exchanges because they’re faster. They’ll dramatically improve auto-completion and spell check. That’s the grunt work of software development that most programmers will be happy to shed.

Generative AI is expected to be applied most often in testing, vulnerability management and writing code, according to an IDC survey of U.S. developers. However, the same survey found that fewer than 10% of developers expect the technology to have value in such creative disciplines as interface design, prototyping or translating user requirements into applications.

Where LLMs Fail

Building enterprise-grade software requires a keen understanding of business concepts and the ability to design novel solutions. That’s where large language models stumble. Trained on a large corpus of existing data, they excel at quickly spitting out what is already known. That can be of great value, but rewording and repetition aren’t the same as creativity.

Generative AI’s main impact on software development will be reducing mundane tasks and giving developers more time to innovate. Automating manual coding may help dent the chronic shortage of software engineers that shows no sign of easing. However, I have not seen any evidence that technology can think outside the box.

Doom and gloom predictions about automation’s impact on the workforce are nothing new. Occasionally they come true. Thanks to automated switching and direct dialing, telephone operator jobs in the U.S. have fallen by more than 95% since the 1950s. Robots continue to reduce the need for humans to do work no one wants to do.

Up the Stack

The more common outcome is for automation to move jobs higher up the value stack.

● E-commerce and customer self-service were expected to doom the retail industry, but total retail employment is expected to grow nearly 8% through 2030, led by services such as home delivery and specialty merchandise.
● About 90% of a commercial airline flight is now fully automated, yet the shortage of pilots is at an all-time high. That job has evolved from flying the plane to overseeing complex systems and being available for rare but critical emergencies.
● Online banking was supposed to kill bank branches, but there are more today than in 2000. Their role has shifted from processing transactions to delivering complex and customized services to the benefit of tellers and customers alike.
● While travel agent employment dropped substantially with the advent of online booking and the end of airline commissions, the industry is growing again, according to the BLS. Many travel agents have thrived by reinventing themselves as experienced consultants and simplifying the complexities of navigating multiple booking sites.
● Healthcare technology has made huge leaps in diagnostics and patient record management, but the need for human judgment, empathy and complex decision-making ensures that the demand for clinicians will remain strong for a long time.

Is the job of a software developer more like a telephone operator or a commercial airline pilot? Any technology executive will tell you the question is absurd. As a founder and CEO, I believe a top-notch full-stack engineer is more valuable than millions of dollars in venture capital. We’ve only scratched the surface of how software can enrich our lives. Automation will free up developers to spend more time on the tasks that make a difference.

February 15, 2024
Best of 2022: Making the Move From Developer to Team Lead

As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

After working in their role for some time, software developers may wonder what career opportunities await them beyond coding. Certainly, taking the next step is not obligatory. Some people feel comfortable remaining developers for their entire professional careers.

However, for those who wish to explore other options, there are a number of different growth paths to choose from—whether it’s working as a solution architect, a Scrum master or a product owner, just to name a few examples.

Another option to consider is a team lead—considered by many to be a position that is a culmination of long-time efforts, passion and dedication as an IT specialist. But is becoming a team lead an opportunity that an ambitious developer should consider?

What Makes a Great Team Lead?

Unlike developers, who usually work on a specific aspect of a project and communicate mainly with other developers, team leads—as the title suggests—are focused on coordinating the activities of and collaborating with the entire team. They also spend far less time dealing with technical issues. A team lead is a leader, a representative and a manager of the team and, as such, their responsibilities involve communicating with both the team members and stakeholders within and outside the company.

A team lead is the first person a developer would go to when a problem occurs and is the person responsible for suggesting a solution. Bug fixes, tooling and library choices or thoughts on how to approach a specific code-related problem—these are the team leads’ specialties since their technical knowledge and experience are what propelled them into a leadership role in the first place.

The Go-To Point of Contact

If you want to improve an application or a test, the team lead is the person to talk to about it. They should know the ins-and-outs of technology solutions and be able to explain to less-seasoned developers why something works and something else doesn’t, or why it may be a good idea to do X instead of Y.

This doesn’t mean, however, that they are all-knowing. Asking other experienced developers for their insight, opinions or to share their knowledge is something good team leads do without fear of losing their authority. They should always be open to other people’s suggestions and welcome innovative ideas.

In addition, team leads should think about a project as a whole, including all the people who are working on it. They can direct developers’ efforts and tell their teams what to pay attention to while making improvements, sharing best practices and taking care of code infrastructure and project architecture.

When to Step Up

It seems obvious that experience, knowledge, passion and communication skills are all things that ultimately make a good team lead. And these skills aren’t developed overnight—they often start as junior engineering or DevOps professionals and gain technical, social and leadership skills before they can guide an entire team or teams.

Sometimes, this progression is a natural consequence of an individual’s personality and work style. A team may notice that one member has more extensive knowledge and/or that one particular person is a natural leader who can motivate others and direct their activities. At other times, team leads emerge spontaneously because of their technical knowledge or they volunteer to gain valuable experience.

For a developer, taking the next step may seem like getting thrown into the deep end. But many current developer skills will be useful in their new role.

For instance, attention to detail—something most developers are known for—can be invaluable as a team lead. Relentlessly analyzing and improving code, for example, is likely to come in handy in a team lead’s work.

The Importance of Soft Skills

Technical know-how, experience, passion, hard work and conscientiousness are the keys to becoming a successful team lead, but it’s also necessary to enjoy working with other people.

A team leader’s job requires communication, collaboration and people skills more than ever before. Collaborating with team members as well as other stakeholders within and outside the company means that a team lead is a central figure in the IT and business processes. Being tech-savvy is great, but leading a team goes far beyond that since it’s about knowledge and experience and being able to communicate about that knowledge and experience.

Another key competency is fluency in English. Using English for coding purposes and communicating in English are two different things. As a team lead, you must talk to your clients and team members, many of whom work remotely and may be in different countries. Of course, you can develop your language skills as you go when you’re a team lead; as with most skills, learning by doing can help with confidence and fluency.

Building language skills can happen simultaneously with building technical and interpersonal skills. Knowledge of various technologies, frameworks and functionalities; experience in working with them; finding ways to change and improve things—all of these give team leads a good reason to practice language skills by talking with colleagues, supervising projects and advising their stakeholders within and outside the company.

Making the Move to Team Lead

With their bottomless willingness to work harder, learn more and take on more responsibility, team leads are an incredibly important role in software development. If you feel that constant development—both technical and interpersonal—is the right course of action for you, then consider becoming a team lead.

Paulina Gatkowska, test automation lead and Robert Musil, Python team lead at STX Next contributed to this article.

December 27, 2022
One-Third of Developers Seeking New Job

With the relentless pace of enterprise digital transformation efforts, even in this softening economy, developers still face an enviable job market. The number of open job positions in computer occupations is greater than 804,000, according to National Foundation for American Policy (NFAP) analysis and, at 326,000 vacancies, software developers have by far the largest number of job openings available to them.

US Developers Are Less Confident About Job Prospects

Still, according to a new report from OutSystems, Developer Engagement Report: Are Your Developers Happy or Halfway Out The Door?, slightly more U.S. developers are seriously considering changing companies right now (33% U.S. versus 31% globally) and they feel less confident about their prospects. Only 25% of U.S. developers strongly agreed that there are many opportunities to easily get a better position right now, compared to 42% of global respondents.

Still, not many developers are thrilled with their current jobs. According to the survey, only 49% of U.S. developers love their jobs and only 37% are very satisfied with the work they do every day. Outside the U.S., developers are a bit more optimistic. Globally, 64% reported that they love their jobs and 46% said that they are very satisfied with their day-to-day work.

Interestingly, when it came to work-life balance, it was U.S. developers who felt more optimistic than their global counterparts. While 50% of all respondents strongly agreed that they need more work-life balance, only 38% of U.S. developers agreed on the same.

Finally, while 48% of developers said that they would definitely be with their current employer within a year, when that timeframe was extended to two years, that figure fell to 29%. And U.S. developers are itchier to move, with only 38% saying that they would definitely be with their current employer in a year and 18% said they would remain there in two years.

Most Low-Code Developers Also Traditional Coders

The report also examined so-called low-code developers. As a subset of the broader population of developers, 59% of low-code developers reported being very satisfied with both team productivity and 57% were satisfied with the quality of tools they use at work. Only 41% of traditional developers felt the same toward team productivity, and only 36% of traditional developers are very satisfied with the quality of the tools they use.

Interestingly, 71% of low-code developers reported that they can keep their workweek to the standard 40 hours, while only 44% of traditional developers said the same. While 63% of low-code developers said that they are happy with their salary and benefits, only 40% of traditional developers agreed. Further, low-code developers claimed an average of 3.5 job promotions at their current company while traditional developers said they’ve been promoted two times.

October 31, 2022
Innovation With Software Architectural Excellence

Software architecture plays an irreplaceable role in enabling businesses to deliver value efficiently. This is evident in how digital natives have been challenging incumbents and forcing them to rapidly digitize and transform how they operate and innovate. Accordingly, achieving architectural excellence is a continuous process of efficient implementation, advanced planning, and executive leadership engagement. Furthermore, it’s essential to recognize that software architectural strategies and planning shouldn’t be limited to IT. Enabling collaboration between IT and business leaders is necessary as software architecture plays a key role in delivering value, making processes robust, and tackling the next wave of changes in value creation and delivery.

The Goal of a Good Software Architecture

A good software architecture facilitates the ongoing business processes function robustly and ensures business capabilities are competitive against threatening challenges. Beyond this, the software architecture should also become the fundamental aspect of driving the next waves of business changes—whether they are processes, models, or innovative products and features. These changes result from competitive forces increasing digitization, transformation, and ecosystem-based consolidation, making change the overarching constant in various business aspects. Accordingly, conventionally viewing a software architecture at a limited software or product level doesn’t work as well as it used to. The practice of viewing software architecture at the business and ecosystem-level gains even more emphasis as digitization and innovation make businesses and ecosystems digitally intertwined in how they interact.

The following fundamental aspects describe how to innovate with architectural excellence:

Security and Privacy

Customers are increasingly becoming wary of how their data is handled and protected—and are even reluctant to do business if an organization doesn’t have clear policies on how it protects and handles customer data. On the other hand, regulators are constantly improving their compliance requirements to protect customers. This landscape is changing at different rates across multiple countries, posing challenges and equally creating opportunities for fast adapters. All of this implies that businesses need to ethically manage customer data along with protecting against the constantly evolving threat landscape. To satisfy this need, it is necessary to revise the existing software architecture and involve senior executives in making critical decisions in this respect. Moreover, architectural planning cycles should come down to a few months—instead of years. This is key to building and implementing innovative solutions rapidly to tackle changing regulatory landscape and customer expectations.

Satisfy User Needs

Since 2008, the smartphone has been changing customers’ experiences and expectations. Digital disruptors are continually challenging incumbents and threatening their survival. In this paradigm shift, businesses should understand their customers more deeply, quickly adapt their business models and introduce new products to fulfill customer needs. It requires architectural agility that offers the flexibility to innovate business models in shorter cycles and improve them faster with customer feedback. This also means keeping a long-term view towards software architecture planning and strategy development that enables seamless innovation and eliminates process and performance bottlenecks. In this view, software architecture improvements and decisions should align with business objectives and strengthen business capabilities, not just the number of implementations or technical solutions the IT has delivered.

Empower Developers

Today, more and more businesses need developers to help them digitize and transform. Accordingly, empowering developers is essential, and software architecture is the fundamental way to help them drive innovation and build critical business capabilities. Developer empowerment is usually measured in terms of developer velocity — it defines how enabled developers are to be agile and how well their talent is utilized. To improve developer velocity, provide them with a well-defined software architecture to focus on quality and consistent development. Also, the software architecture must have scope for customization so that developers can utilize it to its full potential.

While the above describes the overarching approach, the following sections detail the fundamental aspects of achieving innovation with architectural excellence.

Scalability

The software architecture should support scaling applications seamlessly on-demand to accommodate spikes in user growth and scale back to save operational costs. Accordingly, this approach requires deploying your application in the cloud while ensuring not just the underlying infrastructure but also the multiple components in your entire system scale without friction or intervention. High performance should accompany this to ensure customer satisfaction and deliver a superior experience. This means that your system should perform ideally at any scale at any time.

Portability

Can the system itself or components of it be deployed in any cloud platform—public, private or hybrid cloud? How much does it cost to move in terms of time, effort, and cost? In a world of hyperscale cloud providers and cutting-edge cloud services, a company’s IT ecosystem shouldn’t be locked into one platform or vendor but should utilize the best available services and technologies currently—that are also future-ready to improve performance and optimize overall costs.

Compliance

Businesses should develop a compliance framework that aligns people, processes and strategies with regulatory requirements to ensure compliance and avoid non-compliance risks. Also, the framework should be work-in-progress to accommodate upcoming changes from regulators across the board.

Maintainability

Similar to the source code of software components, software architecture should be easily maintainable—meaning that the software architecture shouldn’t introduce bottlenecks when modifying and improving it.

Maintainability issues could take many forms: is the software architecture outdated for the current technical and business landscape? Is it using legacy versions that are incompatible when other components and dependencies are updated? Ensuring the software architecture’s maintainability helps facilitate innovation and move at a competitive pace. If at all unsure where to start improving or redefining a software architecture, start with maintainability.

Cost

IT is often under constant scrutiny to justify its expenditure, and it is complicated to measure IT’s meaningful contribution to the business outcomes. As a result, IT constantly faces the risk of budget cuts and challenges in optimizing costs. Typically, the software architecture is let to grow organically, leading to duplication of system and efforts and inconsistent data across systems. To overcome this, control the software architecture on an ongoing basis, which, in turn, allows for more predictable cost-control.

In this fast-changing landscape of digital, businesses should maintain flexible architectures that facilitate innovation and continually improve the software architecture using agile methodologies to gain a competitive advantage in the business capabilities. This practice is much needed, especially when digital disruptors are increasingly threatening to take it all—leaving laggards behind.

January 17, 2022
When, How and Why to Build a Developer Relations Team

The developer role is changing. More and more often they are being rightfully viewed as key stakeholders who aid in setting company direction in this product-led world that we live in. For many technology vendors, earning the trust of developers is critical to their short-term and long-term success, but this presents a challenge. Developers have more than a full plate of work and traditional marketing tactics can fail to gain their attention. A new, more authentic approach was needed. This has led to the emergence of developer relations (DevRel), a term that can mean a lot of different things to different people.

I view the role of DevRel as being responsible for creating good mutual relationships between a technology company, its product and external developers. Mature DevRel programs typically sit at the intersection of the marketing, engineering and product teams, as it is common to have developers in each of those groups. As such, DevRel teams consist of a unique group of people who fall somewhere in between the developer world and the marketing world. However, DevRel isn’t a one-size-fits-all idea. For early-stage startups, the makeup of a DevRel team tends to be more organic.

When Should an Early-Stage Company Build a DevRel Team?

Creating a DevRel team too early can be a mistake for many early-stage companies. It can be exciting for an early-stage company to want to invest in DevRel from the get-go, but the truth is, putting together this team too early (and before knowing if the product is even a fit in the market) can be money wasted. Developers have long memories, and bringing a flawed or unfinished product to them could create long-term damage to your brand.

You need to first prove your worth in the market and experience growth before investing in DevRel. This way, you can ensure that your hypothesis was correct and your products have proven value. Once you’ve proven your hypothesis and have tested your products thoroughly, the next step is establishing short-term and long-term goals for the DevRel team you want to create. Know your market and have a plan of execution ready.

What Does an Early DevRel Team Look Like?

In the early stages of Algolia, for example, our DevRel team wasn’t even a formal DevRel team. It was a blend of DevRel and customer support. Our first priority was to create the best possible developer experience (DX). We, as developers, took the initiative to interact with the market. We were personally engaging with people that signed up with the service to offer our help.

When your customers are developers, they can find it frustrating to speak to those who don’t understand code; therefore, it can be helpful to embrace a developer-to-developer connection when handling one-on-one support. This is invaluable for helping understand customers’ pain points and iterate very quickly with regards to the product. Imagine hearing about a bug and being able to fix it near-real-time!

The advice I would give to anyone starting an early DevRel team is that your first evangelists should always be your core developers—they know your product inside and out. However, make sure that your core developers are using your product—”Eat your own dog food!” This is a very good way to make sure that your core developers have empathy with external developers. In fact, even today we ask core developers to do support a couple of days per month. As we approached the 150-employee mark, only then did we create a fully dedicated DevRel team. It was only then that we could expand into specialized skill sets to push activities at a larger scale.

How to Engage Your Own Developers to Be Evangelists

Once a strong developer experience is established, DevRel should focus on maximizing inbound activity, not specifically revenue. This can be in the form of free users, trials, student interest, etc. It’s a long-term growth investment. Trying to treat DevRel as a sales strategy and having the goal of impacting revenue is a recipe for failure. You want the developers on your DevRel team to be authentic. They aren’t salespeople; they shouldn’t be salespeople and if they try to be salespeople, it won’t be authentic.

Your developers don’t necessarily need to be overly social or extroverted to embrace DevRel, either—that’s a common myth. They can stay true to themselves and genuinely try to help in ways that play to their strengths. Providing content is a great example of this. Have developers complete documentation for the features they build. View documentation as a core part of the product. For too many people, documentation is an afterthought when, in fact, it is one of the most important aspects of a product. Documentation can then be used as a jumping-off point for other content—blogs, whitepapers, etc.

That said, if your developers are genuinely interested in the more social aspects of DevRel, offer public speaking and training tools for them. Developers with these skills can become the face of the company on webinars and panel discussions, attend events on the company’s behalf and more.

The best DevRel programs understand the developer community, what types of tech they are using and then go where developers are to make connections. DevRel should amplify what the developer community is doing by showcasing use cases and solutions to problems. It should give a voice to your community of users by being the glue between developers and product teams.

Why Do Companies Need DevRel?

The API economy is making the role of developers and DevRel even more important than it already was. The competition for the attention of developers is already fierce; it is only going to increase as more organizations recognize that developers need a seat at the table when strategic decisions are made.

Many companies are going to view DevRel programs through the traditional marketing lens with big-budget bets made on general awareness that isn’t personalized. This is going to fail. Instead, companies that have an authentic and measurable DevRel program in place, built around making meaningful connections, will be the most successful. Early-stage companies that embrace this thinking will gain an edge on larger competitors that are stuck in the old school way of thinking.

December 16, 2021