# Is developer relations right for you? {% embed url="" %} Blog {% endembed %} ## Summary: * Differences between being a product-based software engineer * Pros and cons of this move * Signals in your own life are strong indicators that you might be successful in DevRel * What the DevRel mindset is ## Scribbles * The main focus of the blog is to focus on the ***engineering side of developer relations***. Difference between being a software engineer on a product and a software engineer in developer relations ### Software Engineering vs DevRel - The difference #### **Time spent coding** * ***Product-based software engineer*** the majority of your time is spent working on * features * fixing bugs * writing tests * eliminating technical debt * writing design documents * ***Engineer in developer relations***, there’s simply a lot less time to do all of this * developer relations teams are the connective tissue between 3rd party developers and the internal product and engineering teams * time spent on creating, building, and connecting with communities. * collecting feedback and working with your internal stakeholders to make sure the product is evolving to better serve the developer community #### Size of coding projects * ***not always be the case***, but generally speaking, the size of the coding projects in DevRel is smaller. * building a proof of concept, a demo, a code snippet, or perhaps a client library * your code itself is to be used by other developers within their own projects * building a community, overhauling documentation, amplifying knowledge about a product through videos and speaking engagements -- less coding. #### Part of everything * part engineer, part product manager, part marketer, and part business development. * encounter a lot of different stacks * have to be flexible and learning new stacks on the go. #### Focused on people * DevRel at its’ core is about people * ***software engineering*** is often more about the code you produce * a mix of a great engineer who connects with other engineers and has the respect of the internal teams at the same time caring about people (developers) and making them successful. #### Evaluation of contributions * ***software engineer’s*** impact is likely ***focused*** largely on ***technical contributions*** * ***For DevRel*** * community growth/support * growth of product awareness * product influence * communication regarding product launches * delivery of technical content ### Pros * Requires being good at **a different set of skills.** * You have **a chance to see the world**. * You’ll be **closer to the people** who use the product. ### **Cons** * There are **less DevRel jobs** than software engineering jobs. * Most people understand the value a software engineer brings to a company, it’s not as clear in developer relations. * There's a lot of explaining to do. ### Signs to switch to DevRel * Actively participated in or organized programming events, contests, hackathons, or workshops. * Spoke at technical conferences or meetups. * Have a mixed background of engineering and product or project management. * Academic background or teaching experience of technical subjects. #### *At the end of the day, it's all about the mindset, #DevRel being about people, the **mindset has to be one of empathy.** Their success is our success.* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://scribbles.devrel.page/misc/is-developer-relations-right-for-you.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.