Rick Newman is a Director of Engineering at Salesforce Heroku, and he's joined in conversation with Badri Rajasekar, the founder of Jamm. Jamm was created out of a need for remote and distributed teams to not only work together, but for people to feel connected and invested with each other. Under the belief that remote teams were often confronted with a deluge of emotionless texts--from Slack DMs to PR mentions to email--Jamm makes it possible to send video messages to people in your organization. Meetings can also be open access, allowing curious individuals to pop in and join conversations, or allow audio-video chats to play in the background.

Badri recalls that, early in his career, he believed that the only way people could align together was to establish stringent processes. This could take innocuous forms such as "No Meeting Mondays" or mandating formal summaries after every meeting. But now he recognizes that a culture of creative freedom within teams often results in more organic unity. Creating this organization requires clearly stated goals and trusting that individuals will be able to execute on them.

There also seems to be an artificial tension between synchronous and asynchronous workflows. Badri argues that instead, organizations should recognize that each style of work comes during different periods. Synchronous workflows are often best defined at the beginning of a spring, where product managers, designers, engineers and the like can discuss what problem they're trying to solve. Asynchronous workflows can then go and implement solutions, review code, and ship deployments. Moving past this false dichotomy lets people talk to each other when they want to, not because they need to. Video chats then take the space of being a communication system people look forward to having with each other, rather than a meeting that they are expected to participate in.

• Jamm provides video collaboration for remote teams

J.T. Wolohan is the author of "Mastering Large Datasets with Python," a book that helps Python developers adopt functional programming styles in their their project prototyping, in other to scale up towards big data projects. Greg Nokes, a Master Technical Architect with Heroku, initiates their conversation by lying out what Python is and what it's being used for. As a high-level scripting language, Python was primarily used by sysadmins as a way to quickly manipulate data. Over the years, an ecosystem of third-party packages have manifested around scientific and mathematical approaches. Similarly, its web frameworks have shifted towards asynchronous flows, allowing developers to ingest data, process them, and handle traffic in more efficient ways.

J.T.'s book is all about how to move from small datasets to larger ones. He lays out three stages which every project goes through. In the first phase, a developer can solve a problem on their individual PC. This stage typically deals with datasets that are manageable, and can be processed with the compute hardware on hand. The second phase is one in which you still have enough compute power on your laptop to process data, but the data itself is too large. It's not unreasonable for machine learning corpus to reach five terabytes, for example. The third phase proposed is one where an individual developer has neither the compute resources to process the data nor the disk space to store it. In these cases, external resources are necessary, such as cluster computing and some type of distributed data system. J.T. argues that by exercising good programming practices in the first phase, the third "real world" phasing will require little modification of your actual data processing algorithms.

• "Mastering Large Datasets with Python" teaches you to write code that can handle datasets of any size
• Amazon EMR is a popular way to parallelize data processing in the cloud

Lenora Porter is a Front-End Engineer at Heroku, and she's joined by Sejal Parikh, who is a Product Manager for developer-focused content at Salesforce. Sejal started her technical career in QA, before transitioning into freelance (then full-time) technical writing. When she started her tech writing career, she really had no idea that the field existed, much less what it entailed. She grew to love the role, and the way it called upon her skills of writing and technical knowledge.

Technical writers can be grouped into writing for three categories of users: end users, who need help with user interfaces; administrators, who configure what features are available for an organization's users; and developers, who use APIs to build their own tooling and workflows. In essence, technical writers craft content so that users don't end up stuck whenever they need to solve a problem. These writers often need more sophisticated and complex tooling than word processing software to publish their work.

Even for the writers working with APIs, a background in development is not necessary to be a technical writer. Good use of language and an interest in helping others is enough. When Sejal was starting her career transition, she found plenty of videos on YouTube to help break down the tasks a technical writer might face. She also attended several conferences, and spoke to writers around her, to get a better sense of what the work entailed.

• Sejal volunteered for many years with the Ratan Tata Trust
• OpenAPI and RAML are just two of the formats used for documenting APIs
• The Society of Technical Writing and Write The Docs offer resources for aspiring tech writers

Rick Newman, a Director of Engineering at Salesforce/Heroku, is interviewing Yotam Hadass, the VP of Engineering for Electric, about team productivity. Agile development has been a popular way for teams to plan and execute on strategies, but it's come under criticism lately for being too dogmatic and rigid. Yotam and his team advocated for a different approach: operational agility. A core tenant of operational agility is embracing the idea of iteration. The goal is simple: make a plan, come up with some metrics for what a successful execution of that plan looks like, and when you're done, to review what you've accomplished and where you can improve. This "build, measure, learn" loop runs contrary to the misguided notion that the processes you operate under are forever set in stone.

To start introducing operational agility in your practices, Yotam suggests you first identify what makes your team most productive. For example, it could be your sprint planning processes, development workflows, CI/CD, architectural designs, and even the developer experience that your engineers face looking at the code base. You would continue to ask questions as to which of these are working and which are not, gather new feedback, attempt to resolve them with new strategies, and then continue to iterate on your process.

Although the idea is simple, there can be several challenges to shifting completely to such a different operational approach. First and foremost, it takes time to get started. You need to schedule conversations with every team, decide which questions to ask about your processes, have a strategy on how you're receiving those responses, and finally, turn them into decisions and action. Yotam believe that it takes commitment to proceed from there. From there, you also need to devise a common set of metrics, so that different teams aren't tracking "success" distinctly from the company as a whole. Still, Yotam says that for distributed teams, this common language of working has served Electric very well, in comparison to the top-down managerial approach many companies retain.

Charlie Gleason, Jennifer Hooper, David Routen, Satoshi Nagano, and Chris Castle talk about their various roles in the production of Code[ish], whether that's serving as a host, mixing the audio, or handling the design. The idea for Code[ish] started many years before the first episode was ever recorded. The name came about from the desire to produce a show that was "sort of" about code. From the get go, it was important for Jennifer and the rest of the team to identify several categories which episodes could be placed into: Dev Life (about people and activities), Tips and Tools (about physical and technical tools), Deeply Technical (deep dives into technology), and Heroku in the Wild (how Heroku is being used in production). These tags helped establish a framework very early on.

Although everyone loved the idea, there was a lot of work to be done in the beginning. Someone with audio experience was necessary to suggest equipment and ways to mix the sound. It took a while for the release cadence to get right, because it became very apparent early on that the goal of two episodes a week was too much. And Code[ish] JP, which is a Japanese-language version of the podcast, was also figuring how it should be produced. Little by little, and with encouragement from others at Heroku, both podcasts found their footing.

Producing a podcast is all about listening to questions and ideas, and filtering them into a narrative that makes sense. You have to pair hosts that are passionate about the subject at hand, so that the conversation appears natural, not just a question and answer session. On the technical side, listen to other podcasts and identify what you like about them. Last but not least, always try to learn and improve, by taking listeners' feedback to heart.

• Adobe Audition, Zencastr, and Simplecast is some of the software used to produce the show
• This XKCD comic shows the importance of sanitizing inputs

Chris Castle is a developer advocate at Heroku, and he's interviewing Jonathan Lister Parsons, the CTO from PensionBee. PensionBee operates in the fintech sector, and focuses on bringing a stellar experience for workers managing their retirement funds. PensionBee deals with an industry that is very reliant on paper and ink, and has sought to bring fund management in the UK out of the 19th century and into the 21st.

PensionBee's efforts to change an outdated model isn't just limited to their external business. They also find ways to use technology to improve their company culture. Jonathan believes that technology is at the core of any attempt to reach one's goals. He points out that while many companies say that customer success is their greatest priority, those efforts are often limited in their scope. In order to bring visibility into how they're doing as a company, PensionBee funnels all feedback from their website and apps into a Slack room. When positive praise comes in, teammates celebrate each other. When negative experiences occur, support and engineering band together to address the customer's concerns.

Most software isn't made by people with empathy for their users' goals. All too often, they're built by organizations who are motivated by things other than ensuring user efficacy and contentment. Meanwhile, people are still using tools and processes that are too complex and confusing. There's an innate problem in the corporate world, where decades of investment in IT have still resulted in stagnant productivity rates. For Jonathan, PensionBee striving to resolve that paradox both helps his business and provides a much needed service to its users.

• PensionBee helps its UK users manage their pensions
• The slides from Jonathan's QCon conference talk
• Armie is PensionBee's robot that translates a users' digital signature into one on paper and ink

Esau Sanchez-Diaz is a Customer Success Director at Salesforce, and he is interviewing Amelia Winger-Bearskin, a developer evangelist at Contentful. Amelia Winger-Bearskin is a member of the Seneca-Cayuga Nation of Oklahoma Deer Clan. She has been making art with computers for decades, starting with a Commodore 64 her father brought home one day. Amelia's work often examines the relationship between tech and her native roots. One such example is in her tribe's use of Wampum, which is a sort of contract recording all the activity between two nations. A wampum is comprised of beads of different colors which signal when and between whom an event. As a wampum can span many decades, Amelia relates it to something like the blockchain. Each transaction that occurs on the blockchain is immutable, and since it cannot be tampered with, a history of the movement of data is recorded for all participants.

Some of her projects, like the 3D Beadwork, are just a natural 21st century extension of traditional artisan practices. Through her work, Amelia has been able to build a large cohort with other indigenous people in tech. In order to amplify their visibility, she runs a podcast called Wampum.Codes about the projects they are building.

Mentorship is an important topic for Amelia. She's worked as a professor of animation, and is helping to show the newer generation that a career in the tech industry is possible. Her job as a developer evangelist has helped her hone the necessary skills of meeting strangers and finding common bonds with them. She views her outside mentorship as opportunities to transfer the knowledge she's gained in the industry and to become a good community member.

• wampum.codes is Amelia's podcast interviewing native and indigenous people making cool things with new technologies
• The Co-Creation Studio at MIT Open Documentary Lab researches and incubates alternatives to a singular authorial vision, through a constellation of media methods
• AISES is a national, nonprofit organization focused on substantially increasing the representation of indigenous peoples of North America in STEM studies and careers
• Sundance Institute is a nonprofit organization dedicated to the discovery and development of independent artists and audiences

Chris Castle, a Developer Advocate with Heroku, is joined by Tobie Langel, a longtime web developer and member of the World Wide Web Consortium, or W3C. The W3C is an organization where the standards that define the web are being built. It's a consortium of different industry players, like browser vendors,universities, and governments. These different stakeholders come together and decide how HTML, CSS, and JavaScript API should behave. The W3C effectively lays the groundwork for browsers to agree on how a website should look and behave.

They do this through long, thought out processes of standardization. If each browser ends up implementing its own HTML tags or CSS rules, then the web would become fragmented, as sites would require you to use a specific browser. For something to become a W3C recommendation, two different browsers with different code bases need to successfully implement a specification. This is done to build confidence around an idea, to ensure that browser vendors understand it, as well as to identify ways which frontend developer will make use of the new technology. Much of the conversation between Tobie and Chris goes over how, exactly, this timeline works in practice.

• W3C is the main international standards organization for the World Wide Web
• Specref is an open source database of web standards
• PR Preview adds preview and diff to spec pull requests.

Julián Duque, is a Lead Developer Advocate at Heroku. He's interviewing Matt Pfaltzgraf, the CEO at Softgiving, and Brian Wetzel, its CTO. Softgiving is fundraising platform that allows influencers—whether on Twitter, Instagram, Twitch, or other live streams—to create custom campaigns to raise funds for causes they care about. This is done through custom overlays, as well as rewards and gamification. They're also very hands-on with the content creators they work with, dealing with everything from the design to fundraising goals to determining the incentives for donators.

Providing this level of customer service has been both their distinguishing factor as well as the most challenging part of their work. As demand for their platform has grown, it's required them to scale up their processes massively. They've been able to do this by keeping the processes lean, allowing them to iterate rapidly. Their close collaboration with streamers and charities has enabled them to be experts in both what people need and which groups need the most help. Similarly, their tech stack and app are kept very lean. Anything not essential to the Softgiving platform is handed over to another service, such as payment processing.

• Softgiving is a platform for influencers to fundraise for their favorite causes
• The Givinga Foundation provides the data on charities for Softgiving

Robert Blumen is a DevOps engineer at Salesforce interviewing Doug Fawley, a software engineer at Google. Doug is also the tech lead for the Golang implementation of gRPC. RPC, in general, is a system which enables any client and server to exchange messages. gRPC is Google's extension to the protocol, with support for more modern transports like HTTP/2. This allows for features like bidirectional streaming and stream multiplexing. It also enables better interoperability with load balancing, tracing, health checking, and authentication.

To get started with gRPC, you would define your services and your messages using a language independent schema IDL protobuf. By explicitly stating what data you expect to receive, respond with, and error on, you can build a more reliable way of communication. In fact, many microservices have moved towards gRPC communication as opposed to something like REST, because of this level of introspection.

gRPC is not technically a standard; it is, however, open source, and many languages have implementations against its spec. There's a very active community building tooling and resources, and for that reason, many of the largest software companies in the world have begun to implement it for their services.

You can reach Doug on GitHub @dfawley.

• gRPC is a high-performance, open source universal RPC framework.
• protobuf is a language-neutral, platform-neutral, extensible mechanism for serializing structured data.
• gRPC web provides a JavaScript library that lets browser clients access a gRPC service.
• GRPCurl is a command-line tool that lets you interact with gRPC servers.