Developer Insights
Join millions of viewers! Our engineers craft human-written articles solving real-world problems weekly. Enjoy fresh technical content and numerous interviews featuring modern web advancements with industry leaders and open-source authors.
How to Provide Value to Your Organization in a Developer Relations Role
A few years ago, a multi-billion dollar corporation we all know and love hired what could be perceived as every developer with Twitter influence on the market into a Developer Relations role. Suddenly, everyone you spoke to worked at the said corporation. While many of us were excited to see the value of Developer Relations recognized by a prominent tech organization, many were also left scratching their heads at the alignment, or lack thereof, between what those hired Developer Relations professionals did to “evangelize or build” and how it related to their employer. A majority of those DevRel professionals were not even creating value in communities related to that organization’s products. An insider look will tell you that the reason is that those hired were just told to “keep doing what they were doing” and not given any additional direction or focus outside of that. Without clearly defined expectations, DevRel professionals cannot provide value to your organization. This is not sustainable and no one wants this. Below is a list of four ways that those in developer relations can deliver value to their organizations. Aligning with your Organization's Goals and Objectives DevRel professionals recognize that all activities should be tangentially related to providing value to the organization and ensure that these activities contribute to the organization's goals and objectives. The best way to align DevRel efforts with organizational goals is to make sure you understand what the strategic objectives of your organization are. Is it product awareness? Is it customer satisfaction? Is it revenue growth? Is it pushing new concepts in a market? Is it fostering innovation? Depending on the objective, you will be able to better tailor your DevRel efforts to the organization. Product Awareness as a Goal For example, if the current goal of the company is product awareness, Developer Evangelism is the best way to provide value. Twilio is still the canonical example of evangelism done right. In the beginning, Twilio needed to spread awareness of their product, and show developers how easy it was to use. They did this by showing up at events with developer-centric swag, creating the best tutorials for developers to follow, giving workshops on how to use Twilio APIs, giving talks about how to use Twilio, and creating a strong community of Twilio adopters that shared their use cases around the internet. Through this, the perception was that Twilio was the best solution, and considered the easiest, most obvious tool choice to use when developers were trying to build unique communication features and capabilities like voice, text, chat, video, and email into their applications. Customer Satisfaction as a Goal If the organizational goal is customer satisfaction, then Developer Community and Developer Experience are the two areas a DevRel professional should key in on. By building a community and creating customer feedback loops where developers can share struggles, and their issues can be heard and resolved directly by engineers and product in a quick manner, customer satisfaction will increase because you are helping solve the pain points of using the product. Creating a community allows other developers adopting the product to bond and share solutions in an open forum. Currently, most organizations choose Discord as a way to engage developers and build community. As a DevRel professional, you are in a unique position to help with the Developer Experience in a way that engineers may not be able to. For example, the customer satisfaction metrics may be affected by a lack of documentation, which can easily be solved by improving the documentation where you see the pain points. This does not require engineering or product to get involved and can often solve developer problems overnight. There may be an issue with the migration of one technology to another. Many Developer Relations professionals have built excellent migration tools to help developers ease this pain. Having the flexibility to work outside of the product roadmap and engineering sprints can serve as an invaluable resource for organizations and serving their needs, and the needs of their users. Revenue Growth as a Goal If the goal for your organization is revenue growth, then helping get developers into the top of the sales funnel is key to providing value to your organization. This does not have to be done in a way that compromises the other principle of DevRel or the core value either. One example I’ll bring up again is Test Automation University by Applitools. By providing a free resource that was able to garner the interest of over 150,000 developers through a DevRel initiative (shout out to Angie Jones for leading this initiative), Applitools was able to collect the email addresses of all these individuals and engage them. Since our focus is DevRel and contributing to the top of the funnel, I won’t speak to the “right way” sales or marketing should engage these developers, but I will say it is critical for DevRel to educate and advocate for marketing and sales to engage with these developers the right way that does not erode brand trust. Delivering Value to Your Organization Delivering value to an organization while upholding the core value of authenticity is not difficult. The hardest part is advocating internally to stakeholders within the organization on the approach to developers and helping them understand the “why” behind the DevRel strategy you are employing. Balancing authenticity and providing value to both the community and to organizations allows DevRel professionals to thrive and achieve mutual success for both developers and the organizations they support. Through living these core values and principles, Developer Relations is the way to forge a path of innovation, collaboration, and long-term success in the technology....
Mar 8, 2024
4 mins
This is the Worst Thing a DevRel Team Could Do
At its core, a successful Developer Relations (DevRel) program focuses on forming strong connections within its target audience to ensure that developers can easily connect with the company or organization behind the product they’re using. Great teams in DevRel build genuine relationships, earn trust, and actively engage with developers. DevRel takes a different approach from traditional marketing strategies. Instead of just chasing numbers and leads for sales, it puts emphasis on making developers happy and retention. This creates a cycle of feedback between users and a company, helping to better understand their needs and fostering a sense of community among users. There have been organizations that consider DevRel a revenue-driving function, but this is where challenges arise, since DevRel teams cannot consistently show value in this area and meet the expectations of stakeholders expecting this based on where their focus and the profession lies. When DevRel professionals are forced to be revenue drivers, the breakdown between developers and that company is inevitable. Developers can smell hidden agendas from a mile away. They realize when their needs are being overlooked in favor of sales initiatives. *“Companies fail at DevRel when they try to turn them into sales teams. This hurts customer trust.” - Michael Liendo, Senior Developer Advocate at AWS. * Developers care about education, resources, opportunities, and the overall experience of a product or platform. When they are a target for sales pitches, they leave or shut down. Their focus is getting the job done, and they talk to companies to solve problems in their development lifecycle, not to be on the receiving end of a pitch. Furthermore, since all successful DevRel teams are focused on building authentic relationships with developers, strategic partnerships with other organizations will be hard to come by or have dismal retention numbers since no one wants to be associated with trying to sell to developers. Good DevRel teams are focused on helping developers and understand that being helpful goes a long way to help the sales cycle. Many DevRel efforts also focus on providing value to a community before asking for something in return. The trust and authenticity of brand building in this area and those initiatives - the loyalty a DevRel team is trying to generate - many times does not make direct corollary sense from a monetary perspective, and sales organizations often overlook the non-monetary value and impact these efforts generate and how they correlate to long-term growth for an organization. In DevRel, genuine connections matter more than immediate revenue. When teams prioritize developers' needs over sales, trust grows, fostering lasting relationships that drive long-term success. Treating DevRel as solely a sales function erodes trust and misses the true value of building authentic partnerships and community loyalty. Interested in learning more about launching your own DevRel program, feel free to reach out!...
Mar 6, 2024
2 mins
Intro to DevRel: 5 Reasons Why DevRel Teams Fail
Although Developer Relations (DevRel) defies traditional marketing strategies, prioritizing enhancing developer satisfaction ahead of promoting numbers that contribute to a sales funnel, it is still possible for DevRel teams to fail at delivering desired business objectives. And unfortunately, more often than not, this leads to the dissolution of DevRel efforts, and sometimes even role elimination. Below, I’ve compiled a list of five of the top reasons why DevRel teams fail. 1. Lack of Leadership Buy-In DevRel requires buy-in and support from executives and stakeholders within the company. Without buy-in, being able to work cross-functionally across the organization, get access to data needed for measuring success, have the ability to influence change within the organization, or get the budget for necessary activities to engage developers will be impossible. I asked Jason Lengstorf, the host and founder of Learn With Jason and previously on the Developer Relations team at Netlify and Gatsby, where he has seen companies fail at DevRel before: “Companies that want to invest in DevRel can collect as many well-known developers as they can, but giving them zero dollars and zero autonomy will force teams to rage quit or become content farms because that’s all you can do with no budget.” Other examples are departments not willing to share or give data that helps enable DevRel to understand the metrics they need to effectively baseline and track the success of their efforts. By not doing so, the DevRel team will not be able to justify their work to leadership, which will lead to those positions being cut first when budget cuts come around. Chris Woodruff, Founder of Advocatus, a Developer Relations consultancy, says “DevRel is seeing a lot of layoffs. It’s the easiest team for management to let go because they don’t fully understand the ROI and metrics. These are the holy grails of DevRel, and because they do not understand, they will always be the first teams to let go if management can’t see the actual return or how it affects the bottom line.” 2. Company Culture Fit If an organization's culture does not value collaboration and resists the presence of a DevRel team, DevRel will not be able to effectively advocate for developers or help teams be more successful with their target audience. Francesco Tisiot, Senior Developer Advocate at Aiven, an open-source data platform that makes setting up cloud databases simple, shared one of his experiences in his Developer Relations career. “I was one of the first DevRel hires in a company and we were in the marketing organization. Initially, there was pushback from engineering and product teams on our product feedback and feature requests since we weren't seen as experts. But, DevRel is about breaking barriers and building bridges, so, in leading by example, we demonstrated our technical knowledge and now have a strong impact on all the teams.” Michael Liendo, Senior Developer Advocate at AWS, an online platform by Amazon that provides scalable and cost-effective cloud computing solutions, shared how he was able to find the company culture fit within organizations he has served in the past. Being in a position of Developer Advocacy, and quite literally trying to advocate for developers that use the platform, he says, “Some of the biggest challenges for DevRel are actually internal. Engineers at many companies often focus on one piece of the product. As they're testing features, they may be creating workarounds without realizing they're workarounds. This means they often miss what a proper Developer Experience flow looks like. I've had to push for them to include me in design meetings, and get them to understand that I'm the Lorax--I speak for the community! A phrase I have been known to say is ‘this solves the problem, but it's not a solution’. I'm known for having a high bar for what is considered ‘good enough’ and though the end result is accumulated trust, it's a challenge to get there.” 3. Operating in Isolation DevRel cannot operate in isolation without integration with development, marketing, product teams, sales, or a subset of these. The team will struggle to make a significant impact. DevRel requires a collaborative approach and alignment and synergy with other teams. Francesco Ciulla, Developer Advocate at daily.dev, a professional network for developers that provides the latest tech news and articles, shares his thoughts on how DevRel organizations can be successful within larger organizations: “DevRel organizations can thrive within larger organizations by establishing clear communication channels and fostering meaningful collaborations. They must align their objectives with the company's goals and illustrate their value by sharing tangible outcomes from developer engagement.” 4. Lack of Strategy Proceeding into DevRel without a clear strategy will make it difficult for a DevRel team to establish its purpose within an organization and set priorities that will make an impact. There will not be a clear vision the team can drive towards, leading to wasted efforts and the inability to produce tangible outcomes. If DevRel does not have any goals set, they can only do their best to assume what efforts they should invest in to provide value to the organization. Worst yet, if they do not have any goals set, they may not choose to focus on providing value to the organization, but to a community that the organization has no interest in. Many DevRel experts have seen this happen time and time again in the community, and are always left scratching our heads. Many times, the “strategy” for an organization is to hire DevRel, but that is where the strategy stops. Decision-makers want DevRel professionals to come in and just “do what they do best”. Unfortunately, when decision-makers say this, they typically have an idea of what outcomes they want DevRel to drive, but don’t want to share those thoughts because they feel like DevRel professionals should know what to do. Expectations left open to interpretation often lead to a poor impression of the performance of the DevRel team by decision-makers, and those teams are never able to establish a sense of trust or direction within that organization. Jeremy Meiss, former Director of Developer Relations at CircleCI, says, “One of the biggest problems we have seen in this industry is the startups that were counseled by their VC, founders, or board that they need a DevRel team because the other similar companies had one and it was great for them. They push for it, and one of the early hires is DevRel. Generally, that DevRel hire is someone relatively new in the industry, so you can coax them to start at a new company without clear goals or objectives. New hires like this come in without a lot of experience in the field of DevRel and have not experienced it at different levels of companies. They are heavily pushed by marketing, the CEO, the CTO, and other departments into thinking DevRel should look a certain way, but don’t have the foundational knowledge to be able to push back because they are not yet in this area.” Jeremy’s illustrative explanation of why a lack of strategy ultimately results in the failure of a DevRel team within an organization is one that is common across many devtool startups that have popped up in recent years. 5. Lack of Metrics and Reporting A well-rounded set of DevRel metrics typically comes from multiple areas of the organization, whether that be marketing, sales, product, customer success, or customer support. Without free access to cross-functional team data, it is difficult to show the value and ROI of DevRel. Establishing a baseline set of metrics if you’re new within an organization, or understanding the baseline metrics that currently exist is critical in ensuring the success of your job in DevRel. Tessa Mero, Head of Developer Relations at Appwrite, has a very specific set of metrics her team focuses on. She shared a few of those metrics: - Growth of our GitHub Repo (stars) - Growth of our Discord Community - Improved engagement in Discord community - Growth of our Twitter followers and engagement - Growth of our Appwrite Cloud developers - Number of views or impressions on any video and written content, whether it's internal or externally created - Amount of content created weekly (written or video) - Number of projects created with Appwrite for Hackathon sponsorships - Number of attendees / questions at a conference talk - Number of connections at conferences - Number of community support questions answered, improving rate of responses AND rate of how fast we respond, in all public forums - Number of support tickets responded to - Number of community feedback taken and moved into our DX/Product discussions - Number of feedback from UI/UX perspectives and working with design team to follow up with the devs/users with what we did with the feedback - Number of engagement/activity from our Appwrite heroes/ambassadors This is just one example of and a subset of metrics a DevRel team should consider tracking, but what you track and how you track it is dependent on your goals and the product. Metrics and what your leadership considers a good ROI can vary greatly from organization to organization. I spoke to another Developer Relations expert in the industry and she shared her experience with the company she just left and the reason she left - and it was focused around metrics. She was initially interested in joining the team because of the lack of metrics. However, over time, as she got more experience and as she became more visible, her workload became difficult to prioritize. Since there were no metrics, there were no objectives to measure against to say what was good and what was bad. She felt like she didn’t know what she was doing well or not doing well. Once metrics began to be implemented, the company started pushing her to do more, and she had nothing to push back with because the high-level goals were not there. There was no way to prioritize the workload. The company started tracking things like page hits, unique visitors, unique views of videos, number of subscribers, activity on twitter, and other similar numbers, but it was hard to tie any of these back to the ROI for the company. How do you quantify and determine if 100 new subscribers on YouTube is better than 100 new subscribers on twitter? If you can’t quantify it, how do you prioritize it? What Successful DevRel Teams Do Differently With the nature of DevRel and the multitude of levers and factors that determine success and failure, it’s important to allow space for a team or set of individuals to experiment and iterate before making judgment calls. One company that serves millions of developers on its platform is starting up a new meetup program and testing the ROI of sponsoring meetups around the world. Since they are in the testing and experimentation phase, they don’t yet know how to measure success, and that is clear to leadership. The current strategy is sponsoring local meetups for a few months and seeing what the result is. Why are they so seemingly laid back in their approach? Is it the right approach? The reason for the relaxed nature of the testing phase is that they don’t want to be pushy to the meetup organizer to find something out or measure something. They are not expecting anything, but will evaluate what metrics they could use to establish success criteria. This approach is a thoughtful and empathetic one, and clearly, the DevRel team has an understanding of how to approach community members in a way that will not turn them off. Internally, the simple numbers they are looking at are the number of RSVPs, the number of attendees that show up, and the difference between the two. DevRel is naturally iterative and requires a team to experiment, test, and refine their strategies. Effectively engaging developers is not black and white, and a strategy that works for one community or company may not necessarily work for another. Furthermore, building domain expertise and gaining a deep understanding of the developer community they serve takes time. Experimentation and iteration help teams refine their knowledge, identify patterns, and develop strategies that resonate with developers. This expertise becomes an asset in driving long-term success. It’s also important to acknowledge that building domain expertise within a segment as well as building relationships and trust with developers in that segment takes time. The technology landscape changes quickly and new technologies are being released weekly. Developer sentiment is fickle and changes just as quickly regarding favored approaches and products. That being said, the above pitfalls remain common causes for DevRel teams to fail, and by remaining mindful of and vigilant against them, DevRel teams both new and old can succeed in supporting key business objectives like developer retention, community growth, and product development....
Feb 14, 2024
9 mins
Intro to DevRel: What's the Difference Between External and Internal DevRel Programs?
Developer Relations (DevRel) is a proactive, multifaceted discipline that bridges the gap between developers and companies to drive adoption while cultivating an energetic and supportive developer community for their product, service, or technology. The term and the profession are often misunderstood even among those in other technical roles. Some have never heard of DevRel before, and others believe it’s a kind of tech support for developers. Many organizations even think starting a DevRel program means just giving away free software and hoping it catches on. But DevRel is none of these things. At its core, a successful DevRel program builds strong bonds within their target market to ensure that developers can interface with a company or organization behind the product they’re using. Great teams establish authentic connections with developers, cultivate trust, and actively engage with them. DevRel defies traditional marketing strategies. Instead of prioritizing numbers and eyes that contribute to a sales funnel, it focuses on enhancing developer satisfaction. This creates a feedback loop between users and a company to better meet their needs, and foster a sense of collaboration within a product’s user community. The Two Main Domains of Developer Relations DevRel is split into 2 main domains: external and internal. External: Accessing an existing developer community If a company already has a product with an existing community or a product that may appeal to an existing community, and they want to establish a DevRel program around it, this would fall within the external domain. A successful external program will establish credibility and support developers through a number of evangelistic measures like blog posts, tutorials, webinars, giving talks at meetups and conferences, or creating useful code examples to teach concepts. These activities and their goals are rarely product-specific. Instead, they incorporate a number of technologies within their product’s technical ecosystem to demonstrate its value to a developer’s workflow. I had the pleasure of working with Doron Sherman during his tenure at Cloudinary as VP of Developer Relations. Doron has extensive experience with building developer communities, and successfully advocated internally to build a website called Media Jams, a learning resource for developers working with media in their apps. By having this initiative live under Developer Relations, and not under Product, Marketing, or Engineering, Doron and his team built quickly and created a site that prioritized education, without needing to meet the business objectives of other parts of the organization. > “Media Jams has had great organic growth as a community resource. We were able to attract non-Cloudinary users as well as organic search traffic of those looking for media use cases who would have otherwise gotten lost in the Cloudinary docs and/or could not find help through the Cloudinary blog or knowledge base.” says Doron. Internal: Building a developer community In order to support the adoption and retention of developers using a product, companies must have a space where developers can interface with them. Building their own community around a product is the best way to do this. By creating open lines of communication, developers can provide immediate feedback about a product in a productive way to product and engineering teams thereby shortening the feedback loop and improving the speed at which a team is able to innovate based on user needs. This strategy falls under the internal domain. These forums also provide synergistic opportunities for developers that are using a product to learn from each other. By working on similar problems, developers are able to bond and feel more ownership or excitement toward a product, increasing user retention. Danny Thompson, a developer influencer and mentor who has built a community of over a quarter million followers, says that he admires Appwrite’s DevRel program, helmed by Tessa Mero, Head of Developer Relations: > “The Appwrite DevRel team is great at answering questions. They are on Discord, jumping on calls with developers, answering questions, and doing office hours, all of which are super valuable in building that community. The main difference between Appwrite DevRel and other teams is, a lot of communities are run very passively and not always available or taking an active approach within community forums to help out.” - Danny Thompson on Appwrite. > “When we think about how to become successful as a company through DevRel, our first consideration is, what made us successful in the first place? Appwrite became an open-source company and a successful open-source project because of community, so we focus on a community-first approach. Contributors and developers that have supported us since before we were a company are what led us to where we are now. Every initiative, every planning, and everything we do on our team, we consider the community's feedback and perspective before we make any decisions.” - Tessa Mero at Appwrite. The Value-First Approach to Developer Relations Successful DevRel programs prioritize delivering value to cultivate credibility among developers and support product adoption free from reciprocal demands. External efforts involve engaging with existing technology communities, establishing credibility through various evangelistic measures, and delivering value to the community. On the other hand, internal programs build communities around their product, facilitating direct communication between developers and the company. These internal forums not only enhance user retention but also foster a space for developers to learn from each other, creating a sense of ownership and excitement around the product. And by diverting equity to these two programs, DevRel teams find new users, retain them, and receive invaluable feedback. Real-world examples, such as Doron Sherman's work at Cloudinary and Tessa Mero's leadership at Appwrite, showcase the effectiveness of DevRel in action, and highlight how DevRel programs contribute to the success and sustainability of developer-focused products. In the ever-evolving landscape of technology, DevRel emerges not only as a bridge between developers and organizations, but as a crucial driver of innovation, ensuring products remain relevant, adaptive, and deeply integrated into the communities they serve. If you’re thinking about building a successful DevRel program for the first time, the best place to start is to reflect on some of your favorite brands and how they connect with the developer community. Do they simply distribute discount codes and free swag, or are they reaching out to their users, and providing them a platform to learn, collaborate with others, and contribute? If they are, what methods do they use, and how do those methods coincide with your team’s existing strengths? And if you ever have any questions or want to connect with a DevRel specialist, do not hesitate to reach out!...
Nov 22, 2023
5 mins
How to Start a Developer Relations Program
Developer Relations (DevRel) is a role that’s often misunderstood, undervalued and underrepresented. Some think it's just a marketing department, while others believe it's solely responsible for developer relations. In fact, DevRel is a key part of your company's product team and should be involved at every stage of the product lifecycle—from inception through launch and beyond. The goal of this article is to help you understand the basics you need to start a DevRel program so you can hire the right people, build an effective team structure, measure success, and report on it effectively. What is developer relations? Developer relations (DevRel) is a cross-functional role focused on building relationships with developers, who are users of your product. DevRel plays a critical role in helping teams build and promote their products, by providing support and advocacy for developers. A DevRel team may also be responsible for enforcing developer guidelines, building examples or integrations into your product, or curating content about your product or platform. All of these combined help create a great and sustainable developer experience. How does DevRel fit into your organization? Simply put, DevRel is a strategy and set of tactics that can be used to launch products and platforms aimed at developers. DevRel is not a replacement for product marketing and community management—it's an extension of both, and usually overlaps with these two other practice areas quite often. In smaller organizations, you may have a team doing all three simultaneously! Nevertheless, any DevRel team should be focused on keeping developers engaged in your product throughout its lifecycle. While many companies have developer relations teams, many companies also do not do so intentionally. Some DevRel focused team members may have started out as developers, community managers, or even customer success managers who did outreach to developers on their own initiative. The DevRel role has also been known as Developer Outreach or Developer Marketing; some companies use these terms interchangeably with DevRel. Regardless of what name you choose for this function at your company (or if you choose none), remember that the job is fundamentally about relationships: engaging with people who are interested in your technology through communication channels such as events, blogs/forums/discord/slack/social media accounts, github, etc. When should you start building a devrel team? You should start building a developer relations team when you have a product or platform that is ready to launch and you have a clear strategy for how to launch the product. You should also be able to answer the following questions: - Who is your target audience? - What does your product do? - How does your product work? - What goals are you trying to achieve? If you don’t have a clear answer to these questions, then you need to figure out the answers before you start building a developer relations team. A DevRel person can help you refine how a customer learns about your product, where they can learn more about it (building out developer onboarding experiences), and help you refine the strategy to create a more cohesive developer experience for increased stickiness and adoption. How do you measure success and report on devrel? You can create metrics to measure the success of your devrel program, but you should also keep in mind that it's important not to get too hung up on numbers. When you're tracking impact, it's easy to obsess over data; however, there are other important factors that need to be considered as well. For example, if your developer relations team has been working hard for months and has acquired only a few new customers, that is still worth celebrating because it takes time to build community! You cannot force community and community adoption. It is something that grows with time. When starting, and throughout your devrel program, you want to measure the success of your devrel efforts by looking at more top of the funnel metrics like how many people are visiting or downloading your public-facing content, your social media profiles, and communities. How much value are they getting from your content? Focus on providing value, because consequently, if developers find your content and product/ platform valuable, they will share those links. You should also do competitor research and general industry research in your specific niche and create a baseline! How often are product updates being shared by influencers? How are other products getting developer adoption? These metrics will help give you an idea of what works best for your particular industry. The key is experimenting with different ways of gathering data until something sticks! Conclusion At the end of the day, developer relations is a complex field that can be difficult to understand. But, it’s also not rocket science. It requires an understanding of the market, best practices, and most importantly, authenticity. Luckily, there are many resources out there to help you learn more about it! If you’re interested in learning more about devrel and how it can benefit your company as well as your customers, take a look at some of our favorite articles: - Defining a career path for Developer Relations by Bear Douglas, Developer Advocacy Lead at Slack - What Is Developer Relations? by Justin Warren for Forbes - What is developer relations? Understanding the 'glue' that keeps software and coders together by Owen Hughes for ZDnet - What is Developer Relations by Sam Julien - What is Developer Relations? by Kim Maida We also help with this at This Dot! If you’re interested in learning more about our developer relations program, send us an email anytime! tracy@thisdot.co or sarah@thisdot.co!...
Dec 6, 2022
4 mins
How to Contribute to Redux with Mark Erikson
We are kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. For those interested in React state management, I sat down with Mark Erikson, maintainer of Redux recently! If you would like to check out that interview, you can see it here. What is Redux? Redux is an open source JavaScript library that helps developers manage and centralize global state in their large-scale applications. By wrapping state in a store, you can alert all code that subscribes to the store of updates to the state. Mark Erikson Mark Erikson started contributing to Redux in 2016. After working with JavaScript and Backbone for years, Mark began learning React and Redux, which eventually led him to a chat channel called Reactiflux. While hanging out on these channels, he noticed a ton of people asking the same questions, which inspired him to volunteer to write an FAQ page for the Redux project. Shortly after, Redux co-creator Dan Abramov gave Mark commit rights to the repository, allowing him to triage issues and answer questions. This goes to show anyone can contribute to open source - you just need to get started! What to Know Before You Get Started Before jumping into contributing to Redux, it's important to know a few key things about the repository: - There are three primary repositories within the Redux org. These include redux-core, react-redux, and redux-toolkit. - Redux-toolkit is how the team wants people to use Redux today and where the bulk of the open source work is taking place. - Each repository is structured similarly, so once you understand one, it'll be easy to understand the other two! First Steps for Contributing Since most of the work is taking place in redux-toolkit, new developers will find that it is the most active. In fact, new contributors can learn more, and even help out by reading and responding to questions in the discussions tab located in redux-toolkit as a way to start contributing easily. Redux-toolkit also has many open issues that developers can work on or triage! Developers can help by reproducing bugs or by editing and adding to documentation. If you're interested in helping in redux-core, Mark is looking for TypeScript experts who are interested in reviewing types! If you are interested in contributing but need a little additional guidance, Mark invites you to reach out to him with your questions and he will do his best to get back to you! Good luck contributing, and we hope you have fun submitting your first PR to Redux!...
Mar 10, 2022
2 mins
5 Angular Component Libraries to Use Today
As a Google Developer Expert in Angular, I’ve enjoyed an amazing relationship with the Angular Core Team over the years, and have appreciated the chances I’ve had to collaborate with the team on some amazing events, including semi-annual State of Angular events and so many more. 2022 is gearing up to be a fantastic year for the Angular team, including plans to integrate Strictly Typed Reactive Forms and Standalone Components. Beyond this, in a recent conversation that Core Team Member Mark Thompson had with the Modern Web Podcast, he expressed the team’s unequivocal support for third-party and community tools for supercharging the Angular framework to best serve developers. What will you build to help this reality in 2022?? One of the best supported and most popular classes of third party tools include Component Libraries, which are UI and UX design elements which can be used to simplify both the individual and collaborative developer experience. But with all of the available products, it’s hard to know what Component Libraries are the best in which to invest your time in the coming year. Below, I’ve compiled five well-supported Angular tools that developers can integrate into their builds today! NGXS NGXS is a state management library released in 2018 that is optimal for applications that rely on complex data structures by creating a predictable flow of data rooted in a global data store. Because it is built using TypeScript features, it takes advantage of features including classes and decorators and reduces the need for boilerplates common within state management solutions, allowing developers to use components to interact directly with the store using Actions. NGX- Bootstrap NGX-Bootstrap is an open source library brought to the community by the team at Valor Software, and allows developers to quickly integrate all of the v3 through v5 Bootstrap components under Angular into their application. These components include accordions, pagination, tabs, timepickers, and much more. The benefit of using this exciting component library is that it was built to be flexible, extensible, and optimized for modular systems, with the team also assuring users that they can expect the same degree of performance using these components across both web and mobile applications. Ignite UI Ignite UI is a framework agnostic JavaScript/JQuery component library, created by Infragistics, that offers components that can help developers build engaging, high performing applications in many frameworks, including Angular. Specifically, the tool provides more than 60 components that work within the Angular framework, using Angular Material based native components, and are optimized for use in enterprise applications. Kendo UI for Angular Kendo UI for Angular by Telerik seeks to be the only component library a developer would ever need to build high performing web and applications, providing over 100 native Angular components, and built to promote ease of development, speed, and scalability. If you want to learn more, I highly recommend this tutorial series by my friend Alyssa Nicoll! NG-Zorro NG-Zorro is an open source UI component library containing over 60 Angular Components built using TypeScript to support ease of use in enterprise Angular applications. Some of its notable features include its support of OnPush mode, and its seamless internationalization, supporting the use of dozens of written languages, allowing developers to set the language as they create their applications. — This is not an exhaustive list, and there are so many amazing tools and libraries being built every day. Do you have any other recommendations? I’d love to hear from you! And if you’re interested in learning more about Angular every month, check out angularmeetup.com for ongoing events and updates!...
Feb 24, 2022
3 mins
How to Contribute to Blitz.JS
This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. In the newest episode of this series, looking at the best practices for contributing to open-source web frameworks, I spoke with Brandon Bayer, Founder of Flightcontrol and Creator of Blitz.js. If you would like to check out that interview, you can see it here. What is Blitz.js? Blitz.js is a web framework built on Next.js that offers out-of-the-box features including a “Zero-API” data layer that eliminates the need for REST/GraphQL, and was modeled after Ruby on Rails. Brandon Bayer Brandon Bayer is the Founder of Flightcontrol, a full-stack deploy platform for Nest.js and Blitz.js. Additionally, he is the Creator of Blitz.js, and also offers independent software engineering consulting services. Brandon created Blitz.js after coming from the Ruby on Rails community, and wanting something similar with “batteries included” in the JavaScript ecosystem. What to Know Before You Get Started Developers who are interested in contributing to Blitz.js should visit the Blitz.js repository, read the documentation to learn how to contribute, and discover more about the community! *Quick Tips!* - Check out Blitz Project Dashboard on Github, and view the “ready to work on” column for issues that have been unassigned and need help! - Join the Discord and get involved in the community! The Best Way to Get Started Those who are just getting started with contributing to Blitz.js can help with code reviews, documentation, and addressing issues in the “ready to work on” column in the Blitz.js repository. If you are interested in working on a particular issue, you can comment on it, it will be assigned to you, and then you can start working on it. *Quick Tips!* - To find ideal issues for new contributors, look for the tags “good first issue” and “second first issue”. - If you are using Blitz and you find a bug, you are encouraged to bring that to the attention of maintainers. - If you are looking to build relationships and get involved on a regular basis, you can become a maintainer. There are different levels of maintainers like L1, L2, and Core Team. On the Blitzjs.com documentation page, there are descriptions on what it means to be what type of maintainer. How to Submit a PR Once you submit a PR, someone should review it within a few days, possibly request that you make changes, and then it may be merged. Sometimes PRs might be on hold until there is a release, but usually they are merged immediately. *Quick Tip!* The Blitz.js team doesn't have a lot of people reviewing PRs, so contributors are welcome to look at PRs and comment to make suggestions! What About Attending Core Team Meetings? Currently, the Core Team does not offer contributor meetings. However, earlier in the framework’s history, the Core Team hosted meetings that were recorded and shared on the Blitz.js Youtube channel if you would like to review old meetings. __Are There Ways to Contribute to the Ecosystem Without Coding? Those interested in contributing to the Blitz.js ecosystem without contributing code can: - Help triage issues when new issues come through - if there is a bug, see if you can reproduce it, or ask the original person for details. - Speaking at meetups and conferences. - Making courses and writing books. - Translating the docs into other written languages. - Contribute anything that can spread the word about Blitz.js! Blitz.js Success Stories Aleksandra, who is a TypeScript expert, started using and contributing to Blitz.js. Whenever there was a particularly challenging problem with Blitz in TypeScript, Brandon Bayer would go to her and ask for help. That led to her working full time for Blitz.js! Level 2 maintainers Simon and Juan have been successful too. Simon, who has only recently gotten started with the project, has been super helpful in building items like SuperJSON. Juan got started through translating docs, and he’s been working as a Maintainer ever since. Ready to Begin? You can find the Blitz.js Github repository here....
Feb 17, 2022
3 mins
How to Contribute to RxJS
This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. To continue our series, highlighting best practices for developers interested in contributing to their favorite technologies, I met up with my good friend and creator of RxJS, Ben Lesh. If you would like to check out that interview, you can see it here. What is RxJS? RxJS is a library for reactive programming that uses Observables to make it easier to compose asynchronous or callback-based code. It is a rewrite of Reactive-Extensions/RxJS with better performance, better modularity, better debuggable call stacks, all while staying mostly backwards compatible, with some breaking changes that reduce the API surface. Ben Lesh Ben Lesh is an international speaker and RxJS Core Team Member. His involvement with the framework started a few years ago, when he was asked to work on a rewrite due to his open-source experience in other projects at Netflix. What to Know Before You Get Started According to Ben, the codeofconduct.md and contributing.md documents are the best places for new developers to start. It is crucial that new contributors abide by community standards and the correct commit format, so be sure to read through! *Quick Tips!* -Everything in RxJS is written under src/internal, where you can look at all the internals of RxJS. -The commit message generates the changelog, which can be found on changelog.md. The Best Way to Get Started When I asked Ben what areas of the repository were best for new contributors, and what areas needed the most attention, he of course said: documentation. But it’s true! According to Ben, devs can simply click the “Improve Documentation” button, and do a direct commit. Presently, the team could significantly benefit from contributors interested in checking links to ensure that they are not broken, revising grammatical errors, ensuring all information is up to date, and adding edit buttons in the documentation for individual pages. However, if developers are looking for a different challenge, they can see open requests for contribution by checking out the “help wanted” tag in the issues section. *Quick Tips!* -Don’t simply submit a bunch of PRs to get on the contributors list! Focus on contributing helpful, meaningful work that will advance RxJS! -Because issues are not checked every day, you want to make sure that there is not already a PR for it, and that it hasn’t already been assigned to someone. Also, make sure to look through the PRs to ensure that the issue is not being addressed in both open and closed PRs. What About Attending Core Team Meetings? Core Team meetings typically address in-depth issues and questions related to RxJS, and are not open to the public. However, contributors can receive invitations based on their PRs and need, so if developers are interested in attending Core Team meetings, the best thing to do is create a presence in the RxJS Community! Though meetings aren’t open or recorded, community members can view the issues, and see the tag “agenda item” to see what topics will be addressed at upcoming meetings. Usually, the discussions are commented on in the issues. *Quick Tips!* -If you are interested in getting involved, but don’t want to contribute code, go out into the world and review external articles or Stack Overflow, and help in the community! -Blog posts and explanations about RxJS are also valued by the community and Core Team! Ready to Begin? You can find the RxJS repository here!...
Feb 10, 2022
3 mins
3 Web Performance Concepts that Will Help Start a Conversation Around Performance
In 2021, This Dot Labs released PerfBuddy, the free online platform for testing web and mobile based sites. With the release of this tool, it was our sincere hope to simplify the conversation around web performance, helping team leaders develop easy to understand metrics that they can use to advocate for further investment into their various web technologies. But we also realize that many new to web development, or who work in software but not as developers, might need more clarification on some of the basic key terms to help them engage more actively in conversations surrounding web development. Below, I’ve defined three of the top terms in web performance to help readers better ascertain your site’s performance, and play an active role in refining their technologies to provide the best experience for their customers. First Contentful Paint Time (FCP) FCP, or First Contentful Paint Time, is a critical metric that measures the time that users must wait in order for a page to load its first visible element. For some sites, this could be the entire page. However, for others, the FCP time might measure the seconds between a user navigating to a site, and any responsive element, such as a loading bar, appearing in front of them. This is not a measurement of backend nor even frontend script loading speed, but a metric that affords development teams the ability to infer the quality of their site’s initial UX. According to metrics published by Akamai in 2018, sites are liable to lose nearly half of their visitors if their page takes more than three seconds to load. In fact, just a single second of load time delay can result in a 7% decrease in sales conversions for eCommerce platforms. This is especially true when considering mobile users, whose likelihood of leaving a page increases 90% when made to wait 5 seconds for a page to load And as more eCommerce shoppers turn to using their mobile devices- with 53% of users accessing shopping sites via mobile platforms on 2019’s Cyber Monday, representing a 40% YOY increase- teams need to be acutely aware of their cross platform performance with respect to FCP. Time to First Byte (TTFB) Not to be confused with FCP, TTFB, or Time to First Byte, refers to the amount of time that the browser waits in order to receive initial data from its server. In order for a site to display any information, a browser must make dozens, if not more, data requests. Issues related either to the quality of the host, site functionality, or complexity can all contribute to a site’s latency, or the amount of time it takes for data to be passed between the server and the browser. Of course, reducing site latency will improve user experience by decreasing FCP, and generally increasing browsing speed. However, ensuring low TTFB will also boost your SEO by making your site more quickly crawlable by leading search engines. Page Weight As developers add features and functionality to support more advanced user experience, web pages get heavier. As of 2020, the average desktop webpage weighs 2080 KB, up from an average of 1532 KB in 2017, with the weight of mobile web pages slightly lower, but still seeing a near 40% increase in size when compared to stats from just four years ago. eCommerce websites need to maintain acute awareness of their page weight, and ensure that their latency is not overly impacted by it, due to the tendency for shopping sites to be especially complex, supporting large catalogs of products along with other features to promote customer engagement. And as this era of advanced digital transformation continues to expand, eCommerce sites must develop strategies to meet market expectations for performance without over burdening their sites with heavy plugins and functionalities. Finding Your Path to Performance It starts with equipping yourself with the right tools to test your site’s speed and weight. There are countless platforms used for testing sites, however, there are only a handful that are capable of unlocking the insight that you need to support your most critical websites. Though PerfBuddy is a great place to start in order to identify potential roadblocks, it cannot do the work of actually improving site performance. By leveraging testing platforms such as Lighthouse, and continuously improving your performance metrics with assets such as DevTools, and strategies like Google’s PRPL, eCommerce retailers can ensure that their sites meet user expectations and promote their most critical business objectives. Need help? Contact This Dot Labs to learn more about how developing the tools and strategies to ensure optimal site performance can support scalable growth as you continue refining user experience!...
Feb 9, 2022
4 mins
How to Contribute to Redwood.JS
This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. In our first episode, I sat down with David Price one of the creators and maintainers of RedwoodJS! If you would like to watch this interview, you can find it here! What is RedwoodJS? RedwoodJS is an app framework built on React, Prisma, and GraphQL that is especially useful for startups interested in prototyping since it integrates everything someone would need to carry out fullstack development out of the box. These integrations include Storybook, Webpack/Babel, and more with zero configurations. The goal of RedwoodJS is, in part, to allow developers to focus on what makes their applications unique and interesting by handling a lot of the configuration logic inherent to deploying fullstack applications. David Price David Price is the Founder of human(Ethos), a San Francisco-based consulting firm that helps product teams build cultures of performance, and currently works as a Developer in Residence at Preston-Warner Ventures. Beyond this, David is one of the Creators of Redwood.JS, and serves as a Maintainer. Important Resources to Check Out Before Contributing If you would like to learn more about the specific features offered by RedwoodJS, you can read up on the official documentation here. You can check out the RedwoodJS repository here. David suggests that new users spend time in the packages folder since these are all the packages that will get published to npm. And finally, if you would like to become engaged with other developers interested in RedwoodJS, you can join the official community server and/or the official discord server. The Best Way to Get Started Before contributing any code to RedwoodJS’ open-source repository, David Price suggests introducing yourself to and getting support from the larger RedwoodJS community using some of the resources above: *“The way to get started is to get the moral support in the community, and say you are interested in helping out! And they can direct you!”* Not only will that give new contributors an idea of what current projects are in the works and where they can help, but it can help them connect with other developers who will direct them to the most ability-appropriate tasks. *PRO-TIP from David: There is a file in the repo itself, called contributing.md, that shows you how to get started on actual contributions!* New contributors can also click on the “help wanted” tab in Github issues to see what work is needed, and available! There are also tags called “good first issue”, which are great entry points to the project. Another tag is “bug/confirmed”, which allows contributors to help with bugs! Great at reviewing code? Code reviews support functional testing in the PRs! Inside of the CI checks, there is a link to Gitpod which will pull up a VScode virtual editor that creates a test project. You can use this to help run tests! Anyone can come into a PR, run a test, and go through the process to report back what worked and didn't work. Attending RedwoodJS Contributor Meetups Visit the community forums for RedwoodJS to learn more about how the community is structured. As mentioned above, there are a number of useful discussion boards where you can find information about announcements, docs, and opportunities to contribute. Once you are active on the forums, you will be eligible to receive invitations to private contributor meetups, but be sure to ask for one, since there may not be Core Contributors who are actively searching for folks to invite! Contributor Success Stories - Peter Colapietro started opening and contributing to PRs for Hacktoberfest. Because of his consistent, high quality work since October, he now helps with the Storybook team, working on a really important PR! - There are collaborators working with diversity outreach for Redwood.JS, and they have been brainstorming a lot of ideas on how to get people involved! Multiple contributors have landed jobs after working with RedwoodJS. The community has been growing and evolving. Jobs are being created within the community....
Feb 1, 2022
3 mins
How to Contribute to Angular
This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. To continue our series in which I interview prominent open-source maintainers to find out some best practices for contributing, I spoke with Mark Thompson, Developer Relations Engineer at Google and Angular Core Team member. If you would like to check out that interview, you can see it here. What is Angular? Angular is a Typescript-based open source framework created and maintained by Google and used for building web and mobile applications. Mark Thompson Mark Thompson is a Developer Relations Engineer who began working for the Angular Core Team as a component of his employment at Google. What to Know Before You Get Started If developers are interested in contributing to Angular, they will want to start out by visiting the official Angular repository. Once there, they can find the contributing.md file to get an idea of the guidelines for contributing. After that, contributors will be able to explore the various projects within Angular such as Components, CLI, and more. *Quick Tips!* - Spend time going through the contribution guide, and learn the rules so the Core Team can best help you! There are a lot of automated processes involved! - Sign the CLA before sending any pull request! This is required before the Core Team can accept your PRs! The Best Way to Get Started The easiest place for new contributors to start is in the documentation! Working on the documentation gives you a place to use your existing knowledge, or even your proofreading skills! Anytime you see an issue in the documentation, you can submit an issue and follow it up with a PR! *Quick Tips! - Don’t come in too hot! Don’t use issues as opportunities to attack other developers. No Core Team member or contributor creates anything with the intention of causing intentional harm. - Don’t spam the comments. The Core Team keeps up with comments to the best of their ability and will eventually get to yours. - Go through the feature requests and ‘thumbs up’ the ones that you like so we can make sure they are prioritized! What About Attending Core Team Meetings? Currently, there are no open meetings for Angular, and prioritization meetings are limited to Google employees on the Angular Team and those who receive special invitations. However, anyone can look at the roadmap to find out what the team and other contributors are working on. *Quick Tips!* -Consider hosting your own meetup, event, or creating content for the Angular community. Angular Success Stories Before Minko Gechev became a Googler, he was contributing to Angular. His passion for Angular led to his career at Angular, and he is now the team lead for developer relations. Will your story be next? Ready to Begin? You can find the Angular Github repository here....
Jan 27, 2022
3 mins
Let's innovate together!
We're ready to be your trusted technical partners in your digital innovation journey.
Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.