jackbridger

12 pages of docs vs it’s a textarea. Great job, gonna try it out.

This is interesting. I’m using Claude Code a fair bit and have found writing specs to be more effective than promoting and this feels closer to that. I can see the appeal of this for simple tasks now and maybe increasingly bigger tasks as models get better.

Thanks so much. Great takeaways.

Author here. That's a pretty accurate summary. Fortunately or unfortunately, I don't think there are hidden tricks.

Jack from StreamPot here. So happy to see it shared here. We'd love you to try it out and give us any feedback or requests.

Thanks! Oops, good spot. Updated it. This is where it was supposed to go https://docs.streampot.io/installation.html

Looks great, thanks for sharing.

Author here - thanks for sharing. Aiming to make a page like this for a lot more tools.

Agree. The politician's incentives don't seem very aligned at the moment. Also, feel like there are some shocking things going on with the water companies.

Very interesting and inspiring Story

haha! I don't work in DevRel or at Azure but I can relate. I'd be curious to know who has ultimate responsibility for Developer Experience at Azure.

Thanks so much, really glad you enjoyed it. Yeah sticking with a message was my big takeaway too. Such a challenge when there are shiny new messages always popping up.

Interesting point, I should have made the distinction on company size. Most of my knowledge comes from speaking to early stage DevRel.

I hope I'm not being disingenuous. I'm not disputing that the bottom line always comes down to growth metrics similar to marketing. My goal is to build my own DevTool so my motive is to figure out how all this stuff works.

I'll give you an example. I spoke with Brandon West who was the first DevRel at SendGrid and he said "If you're considering a DevRel job thinking about what size of company you want to join & whether you want to be on marketing, engineering, product side - because DevRel can work on all of those departments. If you want to have your hands on product, then a startup will work better than something with big efficient machinery and you're there to be the spokesperson" https://podcast.bitreach.io/episodes/the-early-stages-of-dev... from 3m5s. Throughout the whole episode the feeling I get is that everything was messy and Brandon was doing everything that needed to be done. He's like a hybrid of engineer and marketer.

You made a good point though and Brandon supports your point too - it seems to be a lot more delineated and specialised beyond the startup stage.

That the work looks more like running or attending hackathons or giving technical talks at developer-focused events doesn't change the goals or measured outcomes.

Great point! You're right the measured goals are similar in marketing and DevRel. I guess that's the question. Is the activity of the role or the objective the defining characteristic of the role?

P.s. there are big debates in DevRel about objectives - check out swyx's great piece on it https://www.swyx.io/measuring-devrel

Thanks for sharing your thoughts, very interesting!

the rest of those functions (docs, tutorials) already have roles.

Which roles have you seen docs & tutorials typically fall under?

DevRel is marketing that targets developers.

I think this is sometimes true but DevRel often make significant contributions in areas that fall outside of marketing too (especially product)

I'll have a go! DevRel is developer relations. The job involves communicating with and supporting developers. DevRel happens at companies whose customers and/or users include developers (think Twilio, GitHub, Stripe). It's an umbrella term and means different things to different companies. But some examples of things they do are: giving technical talks, writing documentation & tutorials, organising developer events, recording video tutorials. It might also include things like improving the onboarding experience. The role exists because developers working on the codebase are busy and tend not to want to spend a lot of time doing external facing work and marketing teams usually don't have the technical knowledge required. It's been around since the 1980s in some form but has been growing steadily in the last 10 years or so.

Well put. Our brains value novelty but that novelty has a messaging cost. As you said, it takes vision at the highest levels to pick a message and stick to it.

Really cool concept, really enjoyed playing with this a few months ago and great to see so much progress - especially emails. I do think it will lower the bar for what's worth writing code for

Interview with Juri - director of DX at Nrwl - the company that founded and maintains Nx

The main ways Nx grew:

- Nx solves a painful problem for companies using monorepos

- Nx maintainers spend part of their time on client work (often related to Nx) and part of their time actually on Nx. This helps them see which are the painful things they need to work on for Nx.

- Founders were on the Angular team at Google and very engaged in Angular community

- NX hires engineers who happen to be engaged in community. A lot are also GDEs and are accustomed to speak at confs, be at meetups etc