Winamp Logo
Code[ish] Cover
Code[ish] Profile


English, Technology, 1 season, 131 episodes
A podcast from the team at Salesforce Engineering, exploring code, technology, tools, tips, and the life of the developer.
Episode Artwork

118. Why Writing Matters for Engineers

In this episode, Ian, Laura, and Wesley talk about the importance of communication skills, specifically writing, for people in technical roles. Ian calls writing the single most important meta skill you can have. And the good news is that you can get better at it, with deliberate practice! Ian and Wesley both come from engineering backgrounds but have moved into more writing-intensive roles as their careers have progressed. Laura is an instructional designer with experience across many industries. They all agree that writing plays several different important roles for people, whether it's to educate, persuade, or even mark a decision. So if writing is such a critical part of what you're doing from an engineering perspective, how can you get better at it? Laura offers a handful of practices, including providing context, supplying the appropriate level of detail for the audience, using stories or analogies, incorporating repetition, and finding a good editor (even if it's yourself coming back to a piece with fresh eyes). The guests close the episode by sharing some of their favorite resources for improving communication skills, which are listed below. Links from this episode “Programming as Theory Building" by Peter Naur Example of an RFC process Illusion of Explanatory Depth The Sense of Style by Steven Pinker Write and Organize for Deeper Learning by Patti Shank Tech Writing course from Google
Episode Artwork

117. Open Source with Jim Jagielski

This episode is hosted by Alyssa Arvin, Senior Program Manager for Open Source at Salesforce, with guest Jim Jagielski, the newest member of Salesforce’s Open Source Program Office (OSPO). They talk about Jim’s early explorations into open source software during his time as an actual rocket scientist at NASA and his role in the formation of the Apache Software Foundation. Next, they discuss getting started in open source, specifically, how to find the right open source community for you to start contributing to. They suggest looking for a code of conduct that the project members take seriously to make sure you’re joining a community that is welcoming and takes diversity and inclusion seriously. Who’s part of an open source community? Well, that would be more than just the contributors--it’s also the project’s end users, even companies who consume it. Those companies have a responsibility to support the projects they use, to contribute back and provide feedback to keep making it better. As an individual contributor (IC), contributing to open source can be part of your growth plan! Leveraging open source contributions to grow your skill helps you become a better employee. Jim encourages companies to adopt as frictionless a process as possible for employees contributing to open source. Salesforce sees open source as a strategic advantage for the company. It’s a way of driving culture, of ensuring that teams collaborate and communicate and, in the process of doing that, drive innovation to benefit not only the individuals who contribute but the company as well. How important is open source to your corporate culture? That will drive how you go about building an Open Source Program Office (OSPO). It really is, at the end of the day, a cultural shift. Finally, Jim shares concrete tips for getting started with your first open source project. He suggests “lurking” in the community and checking their bug tracker for issues marked as “good for newbies.” Most projects have a handful of people who are signed up to be mentors and can help you out. And, look for something like a file that makes it clear how you can get involved and what the future will hold for you as you get more involved. Alyssa closes with the comment that she’s excited to work with and learn from Jim, and we are too! Expect to hear more from him on future podcast episodes. Links from this episode Open Source at Salesforce Apache Software Foundation Open Source Initiative People Powered by Jono Bacon TODO Group InnerSource Commons The Apache Way
Episode Artwork

116. Success From Anywhere

This episode of Codeish includes Greg Nokes, distinguished technical architect with Salesforce Heroku, and Lisa Marshall, Senior Vice President of TMP Innovation & Learning at Salesforce. Lisa manages a team within technology and product that focuses on overall employee success in attracting technical talent and creating a great onboarding experience. The impact of remote work Salesforce is looking at various work configurations across remote and in-office options in different ways. She shares, "In the past 12 months, we've been thinking about what the future will look like. What do our employees want? What do our leaders want for different worker types?" In addition to the fully remote and in-office workers are flex workers who "come into office maybe one, two, three days a week to work with their Scrum teams, or maybe even one day, every other week. You come to an office to work together when it makes sense for you and your team for collaboration and other ways." She notes there's a lot to learn from workers like Greg, who has been working remotely for 12 years. Greg notes, "It took me years to figure out how to work successfully from home and how to have home not encroach on work and work not encroach on home." After unsuccessfully working from the couch, he needed to get an office with a door. Greg stresses that remote work in the pandemic is not the same as remote work at other times. "One of my joys was going to a coffee shop, having a really good cup of coffee and sitting there without headphones on, just listening to people talk while I would write and just that background noise. And I really miss that. So I want to make sure that everybody who's been forced to go remote knows that the present is not a great example of remote work. It's a lot different, and it's a lot harder." Lisa and her team have been talking with other companies who are fully remote and stress that the experience of working fully remote during the pandemic "... isn't normal. We know we all want to see each other. We want to get back together at times where it makes sense." Part of this is focusing on "the things that we can do right now that we want to keep doing in the future when things start to open up." Greg Nokes asserts that a remote-first work approach differs in organizations where remote work is an afterthought. He gives the example of a group of San Francisco employees sending a lunch invitation over a messaging platform, "...and then everyone in San Francisco signed off and when they signed back on, I'm like, ‘What happened?’ They'll go, ‘Well, so-and-so said, where do we want to get lunch? And then we all talked about it in the coffee shop; we're all sitting in, and then we went to lunch together.’ And we're like, ‘that's not remote.’" Lisa Marshall shares the need for intentional inclusivity. "We all know how horrible it feels when you're in a meeting. And when you're a remote person, and others are in the room, and it's very hard sometimes to get a word in edgewise, it's difficult to hear all the common things." Her team is working on organizational guidelines, including team agreements on how people want to work together. One senior leadership team has decided their weekly team meetings will be 100% remote because they found they communicate better when they're all online versus some co-located. How will offices look in the future? Lisa believes the majority of the office will be flex in the future. "So we're looking at how do we want to configure our spaces to support the kinds of work people want to do in the office? What kind of different technologies can we use? What kind of seating arrangements around couches or different pods or other considerations for building in those spaces to be truly about collaboration versus only individual work?" Lisa's team is also focused on trying apps and tools to see what works and start rolling the tech out to other locations. Greg Nokes shares, "The last year has been a tremendous inflection point. And it's given us the ability to re-examine what work is and how we get it done. And I think folks that are just going to go back to the way it was before are really missing out." What are the unique challenges engineering teams face in a distributed/in-person environment? Dev teams are already agile. Lisa asks how they can adapt to remote work in a way that "doesn't burn people out from staring at screens all the time?" She also believes that release planning will change in response to remote work by breaking it up into "smaller increments virtually to do your planning, whether it's two hours a day and having those chunks of time to work together." Fun is important, and recognizing that people can't work non-stop. But we're all pretty tired of Zoom happy hours. Salesforce recently had a paint party and magicians for parents with kids. Equally important is protecting maker time, where developers need to be heads down to get things done without any meetings. Any advice for new remote workers or new hires? Lisa stresses the importance of onboarding new hires. Part of this is about having fun and building relationships through hanging out virtually together, creating an opportunity for new hires to ask questions about who to go to. "And if you don't build that in, it's really hard to just accomplish that because your work is going to get prioritized based on the tasks that you have." Greg also commends the idea of cross-team get-togethers as an opportunity for diverse opinions.
Episode Artwork

115. Demystifying the User Experience with Performance Monitoring

In this episode of Codeish, Greg Nokes, distinguished technical architect with Salesforce Heroku, talks with Innocent Bindura, a senior developer at Raygun about performance monitoring. Raygun provides tools and utilities for developers to improve software quality through crash reporting and browser and application performance monitoring. According to Innocent, the absence of crash reports does not mean that software is performing well. Software can work - but not be optimal. Thus, Innocent takes a holistic view: “I look at the size of my audience, and if it's something sizable, that gets a lot of traffic, for example, a shopping cart that gets a lot of traffic on a Black Friday. I would want to be in a comfort zone when I know that during the peak periods my application is still performing, so I tend to look at the end-user, how their experience looks like during very high peak periods. And from there I start working my way back to the technology that is supporting that application.” Raygun really shines in monitoring the time spent in different functions and helping to improve the performance of highly hit endpoints. This includes performance telemetry of browser pages, the current application running, and server-side performance application monitoring. Raygun has lightweight SDKs or lightweight providers that can be injected into code. These provide a catch-all to deal with unhandled exceptions. They also encourage best practices for developers. Greg asks how to track a user's journey through the application in order to see the endpoints being hit, and the user experience. A RAM tool can provide opt-in user information. In the case of Javascript, an SDK is integrated with code to create a session ID that follows the user through every single page that they visit. This internal ID can also be associated with crash reports. Over time, Raygun can provide a complete picture of how the user session performed “from the point they visited your page, logged in, visited a couple of pages, and then left your application. The crash reports and the traces relating to that particular user are also tied up with that session on the Raygun side.” Innocent highlights a sampling strategy that reduces the noise of APM data. Raygun also provides a birds-eye application view that provides aggregated stats on application performance: “For the run product, you will have each page aggregated over time, regardless of how many users you've had in a period of time. You want to look at the individual sessions. That information is aggregated and you're able to see, for example, your median, your P90, and P99.” Innocent focuses on the P99 figure because “whoever is in there has had a terrible time, and that forms the basis of my investigations. I want to know why there are so many sessions in that P99, and that P99 is probably a six or seven-second load time. I want to move that to a sub-three-second.” Innocent provides a definition of P99 for new customers undergoing the journey of performance optimization. Next, Innocent asserts that decisions should be based on numbers and empirical evidence. He has found that the use of actionable data has enabled him to redesign applications and focus on the mission-critical command needed in real time. Innocent concludes: “I think the life of a developer is an interesting one. We fit in everywhere situations permit, and we definitely take different routes to develop our careers. But ultimately what we should all be concerned about is the quality of the products that I produce. This definitely reflects on my capability as a software developer. What sets me apart from the next developer is not the number of cool techniques I can do with code, it's delivering a product that actually works and what better way of knowing what works when you actually measure things. Everybody should live by the philosophy of assuming nothing, measure everything. Everything and everything should be measured.” Links from this episode Raygun
Episode Artwork

114. Beyond Root Cause Analysis in Complex Systems

In this episode of Codeish, Marcus Blankenship, a Senior Engineering Manager at Salesforce, is joined by Robert Blumen, a Lead DevOps Engineer at Salesforce. During their discussion, they take a deep dive into the theories that underpin human error and complex system failures and offer fresh perspectives on improving complex systems. Root cause analysis is the method of analyzing a failure after it occurs in an attempt to identify the cause. This method looks at the fundamental reasons that a failure occurs, particularly digging into issues such as processes, systems, designs, and chains of events. Complex system failures usually begin when a single component of the system fails, requiring nearby "nodes" (or other components in the system network) to take up the workload or obligation of the failed component. Complex system breakdowns are not limited to IT. They also exist in medicine, industrial accidents, shipping, and aeronautics. As Robert asserts: "In the case of IT, [systems breakdowns] mean people can't check their email, or can’t obtain services from a business. In other fields of medicine, maybe the patient dies, a ship capsizes, a plane crashes." The 5 WHYs The 5 WHYs root cause analysis is about truly getting to the bottom of a problem by asking “why” five levels deep. Using this method often uncovers an unexpected internal or process-related problem. Accident investigation can represent both simple and complex systems. Robert explains, "Simple systems are like five dominoes that have a knock-on effort. By comparison, complex systems have a large number of heterogeneous pieces. And the interaction between the pieces is also quite complex. If you have N pieces, you could have N squared connections between them and an IT system." He further explains, "You can lose a server, but if you're properly configured to have retries, your next level upstream should be able to find a different service. That's a pretty complex interaction that you've set up to avoid an outage." In the case of a complex system, generally, there is not a single root cause for the failure. Instead, it's a combination of emergent properties that manifest themselves as the result of various system components working together, not as a property of any individual component. An example of this is the worst airline disaster in history. Two 747 planes were flying to Gran Canaria airport. However, the airport was closed due to an exploded bomb, and the planes were rerouted to Tenerife. The runway in Tenerife was unaccustomed to handling 747s. Inadequate radars and fog compounded a combination of human errors such as misheard commands. Two planes tried to take off at the same time and collided with each other in the air. Robert talks about Dr. Cook, who wrote about the dual role of operators. "The dual role is the need to preserve the operation of the system and the health of the business. Everything an operator does is with those two objectives in mind." They must take calculated risks to preserve outputs, but this is rarely recognized or complemented. Another component of complex systems is that they are in a perpetual state of partially broken. You don't necessarily discover this until an outage occurs. Only through the post-mortem process do you realize there was a failure. Humans are imperfect beings and are naturally prone to making errors. And when we are given responsibilities, there is always the chance for error. What's a more useful way of thinking about the causes of failures in a complex system? Robert gives the example of a tree structure or AC graph showing one node at the edge, representing the outage or incident. If you step back one layer, you might not ask what is the cause, but rather what were contributing causes? In this manner, you might find multiple contributing factors that interconnect as more nodes grow. With this understanding, you can then look at the system and say, "Well, where are the things that we want to fix?" It’s important to remember that if you find 15 contributing factors, you are not obligated to fix all 15; only three or four of them may be important. Furthermore, it may not be cost-effective to fix everything. One approach is to take all of the identified contributing factors, rank them by some combination of their impact and costs, then decide which are the most important. What is some advice for people who want to stop thinking about their system in terms of simple systems and start thinking about them in terms of complex systems? Robert Blumen suggests understanding that you may have a cognitive bias toward focusing on the portions of the system that influenced decision-making. What was the context that that person was facing at the time? Did they have enough information to make a good decision? Are we putting people in impossible situations where they don't have the right information? Was there adequate monitoring? If this was a known problem, was there a runbook? What are ways to improve the human environment so that the operator can make better decisions if the same set of factors occurs again?
Episode Artwork

113. Principles of Pragmatic Engineering

Karan Gupta, Senior Vice President of Engineering, Shift Technologies joins host Marcus Blankenship, Senior Manager Software Engineering, Heroku in this week's episode. Karan shared his career trajectory, which includes founding, a fast, privacy-first recording and transcription service for investigative journalism, and acting as an advisor for various companies, including Alphy, a platform for women's career advancement. A concept important to Karan is pragmatic engineering. Pragmatic engineering is about having "an oversized impact on the business by applying the right technology at the right time". It's about the technology, the process of creating that technology, and its impact on the underlying business. For example, building an electric car is cool, but producing a version in which people feel safe? That's engineering that changes the world forever. According to Karan, these are the key things that matter in development: Fast-ness (speed) Function (capabilities provided) Form (how it looks and feels) Fabrication (how it is built on the inside) He recalls the value of the snake game on 404 pages. And the value of intentionality, saying "once you add a feature, it's probably going to be there forever. It's probably going to need maintenance and love and care forever. So do we really want to put it in?" He talks about design and the balance between form versus function, such as designing something aesthetically pleasing versus easy to use. Then, there's fabrication: "How well can we make it? Can we deliver it quickly? And can others maintain it?" Sometimes using off-the-shelf software and well-proven frameworks are the most effective, and "Perfect is the enemy of good enough." Karan stresses the importance of being a learning organization. "Be open to picking up what's out there to help make more informed choices, especially if the choice is to stick with the tried and tested." Good engineers are always open to learning about what new things are coming out and open to different opinions, frameworks, and ways of thinking. Links from this episode Shift Technologies Alphy AliceApp
Episode Artwork

112. Managing Public Key Infrastructure within an Enterprise

This episode features a conversation between Robert Blumen, DevOps engineer at Salesforce, and Matthew Myers, principal public key interface (PKI) engineer at Salesforce. Matthew shares his experience running a certification authority (CA) within the Salesforce enterprise. He shares the rationale for the decision to take CA in-house, explaining that becoming a certificate authority means you can become the master of your universe by establishing internal trust. A private or in-house CA can act in ways not dissimilar to a PKU but can issue its own certificates, trusted only by internal users and systems. Using a public certificate authority can be expensive at scale, particularly for enterprises with millions (or even billions) of certificates. However, an enterprise CA can be an important cost-saving measure. It adds a granular level of control in certificate issuing, such as naming conventions and the overall lifecycle. You can effectively have as many CAs as you can afford to maintain as well as the ability to separate them by use case and environment. Further, having the ability to control access to data and to verify the identities of people, systems, and devices in-house removes the cybersecurity challenges such as the recent SolarWinds supply chain attack. Matthew notes that Information within a PKI is potentially insecure “as the information gets disclosed to the internet and printed on the actual certificates which leave them vulnerable to experienced hackers.” Matthews shares the importance of onboarding and people management and the need to ensure staff doesn’t buy SSL certificates externally. Myerss offers some thoughts for businesses considering the DIY route discussing the advantages and limitations of open source resources such as OpenSSL and Let's Encrypt. Identity mapping and tracking are particularly important as you’re giving certificates to people, systems, and services that will eventually expire. Matthew shares the benefits of a central identity store, its core features, and how it works in tandem with PKI infrastructure. There’s also the need to know how many certificates you have in the wild at any given time. As a manager, the revocation infrastructure for PKI implementation means that you're inserting yourself in the middle of every single deal, because if you’re doing it correctly everything needs to validate that the certificates are genuine. When you have a real possibility of slowing down others’ connections, you want to ensure that your supporting infrastructure is positioned in such a way that you are providing those responses as quickly as possible. Network latency becomes a very real thing. Auditability and the ability to trust a certificate authority are paramount. The service that creates and maintains a PKI should provide records of its development and usage so that an auditor or third party can evaluate it. Links from this episode Salesforce Wikipedia page on Public Key Infrastructure Wikipedia page on Certificate Authorities OpenSSL Let’s Encrypt
Episode Artwork

111. Gift Cards for Small Businesses

This episode is a conversation between Heroku developer advocate, Chris Castle and James Dong, developer and owner of Last Minute Gear. The business enables San Francisco residents to buy, rent, and borrow clothing and outdoor gear for activities such as camping, snow sports, and climbing. During the early days of the pandemic, the business was forced to close to comply with shelter-in-place regulations. There was an outpouring of support for small businesses, but not everyone has a Venmo account or wants to donate to a GoFundMe appeal. While many used the pandemic to catch up on Netflix and banana bread baking, James spent a day coding a website and platform where businesses could sell gift cards. It not only helped his own anxiety and insomnia but helped brick-and-mortar businesses like gyms and restaurants (and his own shop) to still earn revenue. It allowed customers to purchase gift cards to be remunerated once businesses reopened. While other platforms with this functionality already existed, James’ project included business-critical functions, such as processing payments and gift cards. James talks about his experiences of anxiety and insomnia which acted as catalysts in making his website operational in just one day. Support from Stripe and Heroku meant there were no fees—all money generated went to the businesses. The conversation offers interesting insights into the value of using a decision logger to document ideas and milestones as well as notes and commit messages to explain why particular decisions were made at certain points in time. It’s also a great example of what can happen when developers build projects that help others in need. Links from this episode Last minute gear — James’ outdoor sports store. Gift Cards for Small Businesses
Episode Artwork

110. Scaling a Bernie Meme

This episode is a conversation led by Greg Nokes, a Product Manager with Salesforce, Dan Mehlman, a Director of Technical Architecture for Salesforce, Mike Rose, a Director of Technical Architecture for Salesforce, Jack Ziesing, a Technical Architect with Salesforce. They're interviewing Nick Sawhney, a college student who saw an opportunity to make his friends laugh and built something that grew beyond his wildest dreams. At the 2021 US Inauguration, a single shot of Bernie Sanders sitting in a chair captured the hearts of many on the Internet. People everywhere were photoshopping him in the unlikeliest of places. Nick utilized his Python skills and quickly built a Heroku app that would allow users to place Bernie anywhere in the world, by adding him to any image available on Google Street View. To say the app was a success was an understatement. Inundated by tweets and distracted by press requests, Nick couldn't devote the time needed to keep the app stable and operational. He sent out a desperate tweet for help, only to be picked up by no less than Dan and Michael, who recruited Jack to help Nick with his operational issues. They paired together in a number of ways, optimizing Jack's Python code, securing its authentication logic, and autoscaling dynos in order to handle the waves of traffic. All of these rapid changes allowed Nick to step back and engage with fans on where they'd like to take Bernie next. In addition to a newfound gratitude towards Heroku's team, Nick learned a few lessons from this experience. He was really humbled by the availability of the engineering community to donate their time and knowledge to help his issues. It's also inspired him to create videos to teach others how they can mitigate scaling issues in their architecture before it becomes a problem. He's also hoping to create some open source tools that to monitor things like server costs and availability issues for other small projects.
Episode Artwork

109. Meditation for the Curious Skeptic

Chris Castle, a developer advocate at Heroku, is joined in conversation with Andrew Lenards, a 20-year programming veteran and meditation coach. He believes that meditation is the practice of familiarizing one's mind with its various states. Concentration is the ability to place attention on something for as long as desired. Clarity is about identifying the sensory experiences in your body. Equanimity is about accepting the state of the world around you. In programming terms, mindfulness becomes a sort of monitoring and observability tool for our bodies. Andrew suggests that curious listeners focus their attention on sourcing materials from secular sources. As well,the benefits of meditation can only come after quite a bit of time. The inclination of most starting practitioners is to quit before investing to see the benefits. Even if you feel like you're doing it "wrong" or feeling your mind get distracted, the core tenant of the practice is to not judge yourself. This in turn will help bring about the calmness which meditation can offer. Links from this episode "The Mind Explained" Niksen is a methodology focusing on "doing nothing" Mindfulness-based Stress Reduction "The Art of Noticing" Search Inside Yourself “99% Invisible” podcast Meditation information on Andrew's site: and Afternoon Idle - 15 min guided meditation via a YouTube live stream Breathe (iOS / Android), Headspace, Calm and Ten Percent Happier are just a few apps which can help your meditation practice
Episode Artwork

108. Building Community with the Wicked CoolKit

Nowadays, the internet is so huge that it can be hard for people to find others who share their niche interests. But when they do find that rare kindred spirit, it can feel like a magical moment. Lynn Fisher and design agency &yet have been exploring ways to help people build community around their passions (which can sometimes be a little “weird”). The team launched a project called “Find Your Weirdos” that incorporates different tools, sites, and techniques for helping people connect with their fellow weirdos. Their project also helps companies connect with customers through niche interests. Inspired by the Weirdos project, the &yet team envisioned ways to help Heroku developers connect — and the Wicked CoolKit was born. The kit harkens back to the earlier days of the internet, when simple, fun web widgets and tools helped people connect without all the noise of today’s mega social platforms. The initial version of the kit offers a new take on a few nostalgic web widgets, including: Developer trading cards — Echoing the retro joy of collecting baseball cards or playing card-based games, this widget allows developers to create their own profile card. They can specify their personal bio, coding skills, niche interests, “feats of strength,” and more, and share it within an elegantly designed UI. Themed stickers — A perennial favorite, stickers are a colorful way to identify interests, such as baking or woodworking. Users can download stickers to use as they wish, or add a sticker to their trading card that links to other people’s cards that have the same sticker. Webring — Years ago, fans and friends would use a webring to share a collection of websites dedicated to a specific topic. The kit brings the old school webring into the modern context and allows people to easily share and access web resources. Hit counter — Everyone wants to know how many visitors came to their site. The old-fashioned hit counter is a fun way to track and display page visits. The higher the number, the more likely people will want to engage with the site (and the developer behind it). The Wicked CoolKit is fully open source and available to use. Links from this episode — Lynn’s personal website. — Home of the Wicked CoolKit Show, don’t tell — the story behind the Wicked CoolKit. — a series of essays on how companies connect with customers through sharing mutual niche interests. — an app that connects to Slack for people to capture and post animated gifs. — digital cards that people can pass around and sign.
Episode Artwork

I Was There: Stories of Production Incidents II

Corey Martin leads the discussion with two developers about production incidents they were personally involved in. Their goal is to inform listeners on how they discovered these issues, how they resolved them, and what they learned along the way. Ifat Ribon is a Senior Developer at LaunchPad Lab, a web and mobile application development agency headquartered in Chicago. For one of their clients, they developed an application to assist with the scheduling of janitorial services. It was built with a fairly simple Ruby on Rails backend, leveraging Sidekiq to process background jobs. As part of its feature set, the app would send text messages to let employees know their schedule for the week; these schedules were assembled by querying the database several times, fetching frequencies and availabilities of workers. Unfortunately, a client noticed a discrepancy between how many notices were being sent out, versus how many jobs they knew they had: of the 400 jobs total, only 150 had notifications. It turned out that all of the available database connections were being exhausted--but that was only half of the issue. Sidekiq was attempting to process far too many jobs at once, and each of these jobs were responsible for connecting to the database, exhausting the available pool. The solution Ifat settled on was to reduce the number of parallel jobs processed while increasing the number of connections to the database. From this experience, she also learned the importance of understanding how all these different systems interconnect. Christopher Ostrowski is Chief Technology Officer at Dutchie an e-commerce platform for the cannabis industry. One Christmas Eve, while celebrating with his family, Chris began receiving pager notifications warning him about some sluggish API response times. Since it didn't really have any significant end user impact, he ignored it and went back to the festivities. As the night went on, the warnings became significant alerts, and he pulled together a response team with colleagues to figure out what was going on. By all accounts, the website was functioning, but curiously, the rate of orders began to drop off. Through some investigation, they realized what was going on. Customers' order numbers were assigned a random, non-sequential six digit numbers. Dutchie was about to track its one-millionth order, a huge milestone. Before any orders are created, though, the app generates a six digit number, and tries to create one that doesn't already exist. The database was constantly being hit, as less and less six digit numbers were available for use. The solution ended up being rather simple: the order number limit was increased to nine digits. Although they had monitoring in place, the data was set up as an aggregate reporting; even though the "create order" API was slow, all of the others were low, keeping the average within tolerable levels. Christopher's solution to avoid this in the future was to set up more groupings for "essential" API endpoints, to alert the team sooner for latency issues on core business functionality. Links from this episode LaunchPad Lab is a web and mobile application development agency Dutchie is an e-commerce platform for the cannabis industry
Episode Artwork

107. How to Write Seriously Good Software

Rick Newman is a Director of Engineering at Salesforce Heroku. He's joined by Marco Faella, a professor of advanced programming and author of "Seriously Good Software." In Marco's view, there are of course several ways ways to characterize "good" software. Excellent software that goes above and beyond correct functionality includes code that is readable, robust, and performant. Each of these have different importance, depending on context. Robust software, for example, includes addressing issues with scalability, but only if one expects the software to be in such a high availability environment. It's important to address these requirements from the beginning, when the software architecture is being mapped out. Marco gives the example of developing software for an external client. This client might know all the business logic and how it ought to function, but addressing the code's future evolution and maintenance are just as important, and whose responsibility lands squarely in the hands of the developer. It can also be worthwhile to make an investment in education, learning about algorithms, data access, and other key concepts in the world of computer science. Such a foundation would allow one to adapt to the changing conditions of programming, whether those are caused by new hardware or modifications in the languages themselves. Links from this episode "Seriously Good Software" is Marco's book on the subject of writing strong code -- get a 40% discount with the code podish19
Episode Artwork

106. Growing a Self-Funded Company

Host Greg Nokes is a distinguished technical architect with Heroku. His guests are Alli McGee, a product manager, and Lewis Buckley, a senior application engineer, from BiggerPockets. BiggerPockets was founded 16 years ago to educate non-professionals about real estate investing. As a self-funded company, it’s critical for BiggerPockets to create products that customers will pay for. One way they achieve this product/market fit is by building cross-functional teams that are user-focused. All product teams have a project manager, tech lead, and designer that work closely together. This design-led approach allows teams to collaborate with representation from users, technology, and design. As the PM on one of these teams, Alli lives at the intersection of what can we do for business, what can we do from a technology perspective, and what can we do for the user. She advocates for the customer, bringing knowledge of what customers want, what problems they are facing, and how they have interacted with prototypes in usability studies. Alli also advocates for the business to be sure products make money. Finally, Alli advocates for developers to make sure the project is technically feasible and won’t cause technical debt. Another way BiggerPockets creates market fit is by creating Minimum Lovable Products—the smallest cheapest thing they can build that people love. With their current product, BP Insights, Alli and Lewis used this strategy to create the first iteration of a product that provides insight into local real estate markets. They then tested the product with users, iterated, and slowly built out a more fully formed offering. For their tech stack, BiggerPockets is built on a Ruby on Rails monolith. While some in the industry say Ruby on Rails’ time is over, Lewis argues that it has been a great choice, as using a well-known stack has allowed them to worry less about the technology and focus more on building value for users. The BP Insights product was built on this monolith using a massive data set of nearly every property in the US. BiggerPockets imported the data to an Amazon S3 bucket and eventually copied the data to Amazon Redshift for querying. Links from this episode BiggerPockets
Episode Artwork

105. Event Sourcing and CQRS

Robert Blumen is a DevOps engineer with Salesforce, and he's joined in conversation with Andrzej Ludwikowski, a software architect at SoftwareMill, a Scala development shop. Andrzej is introducing listeners to the concept of event sourcing against the more traditional pattern of CRUD, which stands for create-read-update-delete. CRUD systems are everywhere, and are most typically associated with SQL databases. In comparison, event sourcing is a simply a sequential list of every single action which occurred on a system. Whereas in a database, a row may be updated, erasing the previous data in a column, and event source system would have the old data kept indefinitely, and simply record a new action indicating that the data was updated. In a certain sense, you can get the state of your system at any point in time. Each architectural pattern has its pros and cons. For one, an event source system can make it easier to track down bugs. If a customer notes an issue an production, rather than pouring through logs, developers can simply "rewind" the state of the application back to some earlier event and see if the faulty behavior is still there. On the flip side, since the event stream is immutable, fixes to previous data needs to be made at the end of the stream. You can modify old events or insert new ones into the flow. CQRS, or Command Query Responsibility Segregation, builds on top of event sourcing. The idea is to separate the part of the application responsible for handling commands and writes from the part responsible for handling queries and reads. This separation is not only on a software level (different repositories and different deployments), but also on the hardware level ( different hosts and different databases). The motivation for this is to be able to scale each part independently. Maybe your app has more writes than reads, and thus requires different computing power. It allows for a separation of concerns, and can make overall operations more efficient, albeit at a complexity cost. Andrzej is quick to note that event sourcing and CQRS divisions are not necessary for every application. Teams, as always, need to understand how the data flows in their application and which architectural pattern is most efficient for the problems they are trying to solve. Links from this episode SoftwareMill is a Scala development shop Martin Fowler gives a brief run-down on event sourcing On the SoftwareMill blog, Andrzej has a blog posts on entry-level event sourcing, keeping your domain clean in Event Sourcing, and the best serialization strategy for Event Sourcing provides more educational resources Andrzej Ludwikowski's web site and talk Event Sourcing: What could go wrong?
Episode Artwork

104. The Evolution of Service Meshes

Luke Kysow is a software engineer at HashiCorp, and he's in conversation with host Robert Blumen. The subject of their discussion is on the idea of a service mesh. As software architecture moved towards microservices, several reusable pieces of code needed to be configured for each application. On a macro scale, load balancers need to be configuring to control where packets are flowing; on a micro level, things like authorization and rate limiting for data access need to be set up for each application. This is where a service mesh came into being. As each microservice began to call out to each other, shared logic was taken out and placed into a separate layer. Now, every inbound and outbound connection--whether between services or from external clients--goes through the same service mesh layer. Extracting common functionality out like this has several benefits. As containerization enables organizations to become more polyglot, service meshes provide the opportunity to write operational logic once, and reuse it everywhere, no matter the base application's language. Similarly, each application does not need to rely on its own bespoke dependency library for circuit breakers, rate limiting, authorization and so on. The service mesh provides a single place for the logic to be configured and everywhere. Service meshes can also be useful in metrics aggregation. If every packet of communication must traverse the service mesh layer, it becomes the de facto location to set up counters and gauges for actions that you're interested in, rather than having each application send out non-unique data. Luke notes that while it's important for engineers to understand the value of a service mesh, it's just as important to know when such a layer will work for your application. It depends on how big your organization is, and the challenges you're trying to solve, but it's not an absolutely essential piece for every stack. Even a hybrid approach, where some logic is shared and some is unique to each microservice, can be of some benefit, without necessarily extracting everything out. Links from this episode HashiCorp helps automate infrastructure configuration Consul, Linkerd, Istio, and Kuma are several open source components for service meshes and control planes Mastering Service Mesh: Enhance, secure, and observe cloud-native applications with Istio, Linkerd, and Consul by Anjaki Khatri and Vikram Khatri Consul service mesh What's a service mesh? And why do I need one? by William Morgan offers additional advice on when to use service meshes The Service Mesh: What Every Software Engineer Needs to Know about the World's Most Over-Hyped Technology What is a Service Mesh? - a blog from NGINX
Episode Artwork

103. Chaos Engineering

Rick Newman interviews Mikolaj Pawlikowski, who recently wrote a book called "Chaos Engineering: Crash test your applications." The theory behind chaos engineering is to "break things on purpose" in your operational flow. You want to deliberately inject failures that might occur in production ahead of time, in order to anticipate them, and thus implement workarounds and corrections. Typically, this practice is often used for large, distributed systems, because of the many points of failure, but it can be useful in any architecture. One of the obstacles to embracing chaos engineering is finding high level approval from other teammates, or even managers. Even after the feature is a complete and the unit tests are passing, it can be difficult to convince someone that some resiliency work needs to continue, because there's no visible or tangible benefit to preparing for a disaster. Mikolaj suggests that people clearly lay out to other colleagues the ways a system can fail, and the impact it can have on the application or business. Rather than try to fear monger, it can be useful to point to other companies' availability issues as words of caution for their teams to embrace. Mikolaj also says that chaos engineering doesn't need to focus solely on complicated problems like race conditions across distributed systems. Often, there's enough low hanging fruit, such as disk space running out or an API timing out, that can be useful to consider fixing. The chaos engineering mindset can also extend beyond pure software. If you think about people working across different timezones as a distributed system, you can also optimize for failures in communication before they occur. Everyone works at a different pace, and communication issues can be analogous to a network loss. Rather than fix miscommunications after they occur, establishing shared practices (like writing down every meeting, or setting up playbooks) can go a long way to ensuring that everyone will be able to do their best under changing circumstances. Links from this episode Mikolaj's book is called Chaos Engineering: Crash test your applications -- get a 40% discount using the code podish19 powerfulseal is a testing tool for Kubernetes clusters Mikolaj distributes the Chaos Engineering Newsletter Conf42 is a conference focusing on high-level computer science ChaosConf is the world’s largest Chaos Engineering event Awesome Chaos Engineering is a curated list of Chaos Engineering resources
Episode Artwork

102. Whether or Not to Repeat Yourself: DRY, DAMP, or WET

Robert Blumen is a DevOps Engineer at Salesforce, joined by Ev Haus, Head of Technology at ZenHub. Together, they're going over a critique over several methodologies when writing code as part of a large team. First, there's DRY, which stands for Don't Repeat Yourself. It's the idea that one should avoid copy-pasting or duplicating lines of could, in favor of abstracting as much repeated functionality as possible. Then, there's DAMP, or Don't Abstract Methods Prematurely, which is somewhat in opposition to DRY. It advises teams to not create abstractions unless they are absolutely necessary. Last on the list is WET, or Write Everything Twice. This is the idea to embrace duplication whenever possible. Ev notes that, like many programming absolutes, the success of each strategy depends entirely on the context. DRY, for example, sounds like a really good idea, until it happens everywhere. Suddenly, a chunk of code becomes difficult to reason, as a developer jumps around various method definitions to piece together a flow. DAMP often makes sense as a counterpart to DRY, because if you abstract too early in your codebase, you may find yourself overloading methods or appending arguments to handle one-off cases. DRY is typically best suited for testing environments, where an absolutely reproducible set of explicit steps is often preferable in order to quickly understand what is occurring. No matter the strategy you use, the core tenant is to solve the problem first. Try to accomplish the goal you need to, whether that's adding a feature or squashing a bug. Don't over optimize until you've finished what you need to, and don't think too far into the future about all the possible edge cases. The rest of the balance comes with experience. Some duplication is bad, but not all of it. Figuring out the absolute perfect solution is unlikely, so you've got to put the code out into the real world to find out what works. After that, bake some flexibility into your processes to adjust hot code paths or refactor them when needed! Links from this episode ZenHub is an agile project management tool for GitHub Wikipedia's definition of DRY "Using DRY, WET & DAMP code" is Ev's article on different coding methodologies Codewars is a website with programming puzzles and challenges The Pragmatic Programmer by Dave Thomas is a popular book highlighting some of these concepts DRY code, DAMP DSLs by Jay Fields and DRY vs DAMP in Unit Tests by Vladimir Khorikov are more write-ups on the subject
Episode Artwork

101. Cloud Native Applications

Host Joe Kutner is an architect working at Salesforce, and his guest is Cornelia Davis, the CTO of Weaveworks, a platform for infrastructures. Cornelia argues that most companies building complex web-based applications are doing so without fully understanding the unique operational challenges of that environment. Even several well-known patterns, such as adding circuit breakers or retry patterns, are not standardized across the industry, and certainly not across languages, let alone in frameworks and other easily consumable dependencies. In many cases, there are over reliances on infrastructure availability that only become obvious once a problem occurs. Cornelia gives the example of a massive AWS outage that occurred several years ago. For many companies lacking redundancy contingencies, their applications were offline for hours, through no fault of their own. Another potential conflict between operational patterns and software design emerges around container-based lifecycles. If you have a new application configuration that you want to deploy, Kubernetes, which is designed to be stateless, encourages you to simply get rid of a pod and start up a new one. But it's entirely possible that there's some running code that doesn't know how to pick up these new changes, or even a service which can't recover from unexpected downtime. Considering these issues is the difference between running the cloud and being truly cloud native. To the industry's credit, Cornelia does see more platforms and frameworks adopting these patterns, so that teams don't need to write their own bespoke solution. However, it's still necessary for software developers and operational engineers to know the features of these platforms and to enable the ones which make the most sense for their application. There is no "one size fits all" solution. As the paradigms mature, so too does one's knowledge of the interconnected pieces need to grow, to prevent unnecessary errors. Links from this episode Weaveworks automates enterprise Kubernetes The twelve-factor app Cornelia wrote a book called Cloud Native Patterns (get a 40% discount using the code podish19)
Episode Artwork

100. Math for Programmers

Hailey Walls is a Customer Solutions Architect with Heroku, and she's engaged in a conversation with Paul Orland, the founder of Tachyus and author of Math for Programmers. Paul took graduate level math classes, and even ended up with a Master's degree in Physics, but even he admits that he comes down with his own kind of math anxiety. Now, he works as a programmer, building predictive models, but he encounters many engineers who don't have a basic understanding of fundamental math concepts, like calculus or linear algebra. Seeking to rectify this, he wrote a book called Math for Programmers, which methodically explains mathematical concepts using real-world examples. He hopes to be able to teach math to many more people. Paul emphasizes that, although thinking of mathematics can be intimidating, it's not different than working on any other skill. If you decide to go weight lifting, you start with a 10 pound weight, then a 15 pound one, and on and on. Similarly, with math, if you train on problems that are simpler, future problems will build upon the techniques you've honed. The appeal for gaining math skills is almost analogous to that of programming: there is always a right and final answer. Just as a compiler determines how a program works and whether a syntax is valid, taking in input and producing output, so too is math deterministic. Fundamentally, better mental acuity with math can help teach you how to consider the behaviors of complicated systems. For people interested in studying math more closely, Paul advises students to not be discouraged by problems which appear hard. It can be best to pick a problem that you are naturally interested in, which will lead to a general willingness to try and solve it. Similarly, he'll also take a math concept and turn it into a program, which has helped him reason about flow and patterns much more clearly in the past. Links from this episode Tachyus helps energy producers optimize their production Math for Programmers is the book Paul wrote -- listen for a 40% off code
Episode Artwork

99. The Technical Side of Deep Fakes

Julián Duque is a Lead Developer Advocate at Salesforce and Heroku, and he's continuing a previous discussion with some members of Respeecher. Respeecher has created AI software which works within the speech-to-speech domain: it takes one voice and makes it sound exactly like another. Dmytro Bielievtsov, its CTO and co-founder, explains the practical uses of the software, such as re=recording the lines of an actor who is unavailable, or bringing historical figures to life in a museum. In terms of sophistication, there are quite a few speech ML models already available on the Internet. The best source of audio to duplicate the speech patterns of a famous person is to grab an audiobook and pass it through one of these pre-existing models. But these models produce outputs which are poor in quality. That's one reason that speech-to-speech is hard to fake. The variation in our mouths and speech patterns, not to mention the emotive qualities, make the process of creating duplicate voices extremely difficult to pull off. One way Respeecher data can't be faked is by the fact that they position themselves as a B2B business, dealing with studios and other large estates which have access to immense amounts of hard-to-acquire sound data. The likelihood of another entity abusing a well-known voice is close to none. Another feature is that the audio is watermarked. Certain "artifacts" are embedded into the audio, which are imperceptible to humans, but easily identifiable by a computer program. There's a consortium of several companies working on synthesized media who strategize in Slack on various ways to keep the tech from being misused. As well, Dmytro believes that there needs to more investment in education, to let people know that such technology exists, and to therefore be a bit suspicious with media they encounter online. Links from this episode Respeecher is a speech-to-speech voice cloning software Google's DeepMind and Tacotron are two popular AI/ML projects Module empowers the future of identity, online safety, and communication through voice Previous episode: 98. The Ethical Side of Deep Fakes
Episode Artwork

98. The Ethical Side of Deep Fakes

Julián Duque is a Lead Developer Advocate at Salesforce and Heroku. He's joined by Alex Serdiuk, the CEO of Respeecher. Respeecher has created AI software which works within the speech-to-speech domain: it takes one voice and makes it sound exactly like another. Alex rejects the premise that all deep fakes--that is, pictures and videos generated by AI--are inherently evil. He considers tools like CGI and Photoshop to fall within the realm of synthesized media, which helps artists create content. He positions Respeecher within that same mileu. Respeecher has been working with Hollywood studios for some time. It removes pressure from actors who are unable to rerecord lines. It's also been used in situations where actors need to sound much younger, a visual-audio process called de-aging. In the future, applications of speech-to-speech work could also be used in museums, to provide a new dimension of history for audiences. Of course, Alex recognizes that the main issue with deep fakes is not their existence, but their inability to be detected. To solve this problem, Respeecher watermarks its audio, to generate inaudible metadata which can nonetheless be analyzed to show whether a particular recording was faked. He also believes that more people need to be educated that synthesized media exists. Something one sees or hears might not be real, because technology is getting more and more advanced. We should all be mindful about the content we consume. Links from this episode Respeecher is a speech-to-speech voice cloning software Samsung Next provides an overview of the synthetic media landscape
Episode Artwork

Special Episode: Health Metrics at Scale

Jacob Silzer, Trusted Security Director at Heroku, is co-hosting this episode with Trey Ford, VP of Platform, Trust, and Strategy at Salesforce. They're sitting down with Tim Panagos, CTO of Microshare. Microshare began as a platform to aggregate wireless sensor data from IoT devices. Much of their use cases were for smart offices; for example, seeing how occupied a conference room was, whether a hot desk was open, and when a particular area had been cleaned. For hospitals, their platform monitored physical equipment, such as patient beds and medicine carts. These devices ran on a LoRaWAN network, which doesn't communicate through Wi-Fi, making it ideal for secure locations. Then, COVID hit. Suddenly, information from these devices, where were useful from a logistic and compliance standpoint, became extraordinarily important. By tracking the amount of people in a room, the amount of times an area was cleaned, or the movements of an unknown carrier, whole industries can monitor their overall health efficacy, comparing their performance not only with their past, but also, with other similar businesses. Tim gives the example of an airport here: one could potentially see how their cleaning efficiency is compared to other airports around the world. Part of the success of their platform is their reliance on the blockchain. Businesses can monitor not only how their data has changed over time, but they can look back on any block and identify what factors may have contributed to a decreased in performance. Tim notes that the platform is not bulletproof. For starters, tracking equipment requires people to remember to add trackers; a simple error, to be sure, but one which is frequently forgotten as new crash carts are added to quickly meet increased demands. But more urgently, no one really knows how the future will change in response to the knowledge we only currently have. Microshare was only able to pivot because they were wise enough to recognize that their business and their software needed to be flexible. They essentially threw out their 2020 roadmap in order to focus on tracking clean air and open spaces. The best way to move forward is not just to collect more data, but to also add context to it, which will create meaningful value. Links from this episode Microshare is a data leverage platform utilizing IoT devices LoRA Alliance is a non-for-profit group consisting of companies committed to LPWAN
Episode Artwork

97. The Challenges of Bespoke Solutions in a Regulated World

Greg Nokes, a Master Technical Architect with Heroku, interviews two members of Yobota, a banking systems provider: Ammar Akhtar, its CEO and co-founder, and James Maidment, the head of Technical Operations. The financial industry is heavily regulated. As it stands, it was only until about 2016 that the UK (where Yobota is based) gave favorable guidance for vendors to operate in the cloud. As a service provider, the banks that use Yobota are audited by the Financial Conduct Authority. As part of that audit, every single deployment performed over a year is examined. Regulators select a random set of them, and Yobota has to demonstrate that they know who was involved in the release, and precisely which services were affected. Thus, their entire shipping process is revolved around meeting this regulation goals. They're an integral part of the company, just as data security and uptime availability are. The platform is designed in such a way to both evolve quickly and quickly perform safe deployments that are observable. Unlike other startups, Yobota has decided to invest in a sysadmin team, in order to split the organization between people who develop features and people who manage their compliance. For example, as the company grows, they've found that active hands-on management of permissions has been a valuable investment. Different groups need access to staging environments versus production environments; and, with over 300 apps on multiple dynos, access to resources needs to be carefully configured. This is seemingly slow shipping process is advantageous for two reasons. First, meeting compliance is the law, and flirting around that has tremendous consequences. But second, and more importantly, Yobota also provides fake environments for their engineers to develop around. They're able to give developers the ability to experiment with their platform in a safe way; should they choose to advance a feature into a production environment, a different team is able to address what needs to be done to meet the needs of that regulated environment. James suggests to other companies working in these sorts of industries to consider compliance integral to the way their systems operates, and to think about concerns upfront, in advance of working on any feature. Links from this episode Yobota is a core banking platform that allows financial institutions to launch innovative products in a fast and reliable way
Episode Artwork

I Was There: Stories of Production Incidents

Corey Martin values storytelling. It's just one way developers can share their experiences in order for others to take lessons. To that end, this episode takes a close look at production issues from two different applications to examine what went wrong and how it was fixed. Meg Viar is a Senior Software Developer at Nomadic Learning, an e-learning platform. One day, they noticed that, for a certain group of users, a column of information in their database row was nulled. It didn't look like any user--either internally or externally--intentionally changed these values, and there hadn't been any new code deployed in days. The only clue was that the data was all changed at the same time. It turned out that a weekly cron job was deleting some data on an in-memory list. However, the database ORM they use also overloads the delete keyword, and was actually deleting the production data. Restoring the data from a backup was easy, and reworking the code to not use the data was a quick fix. However, going forward, Meg and her team came up with several ways to adjust the process around code changes like this from occurring again. Brendan Hennessy is the co-founder and CTO at Launchpad Lab, a studio that builds custom web and mobile applications. One of their clients is an SAT/ACT test prep app, and students complained that the app was extraordinarily slow. Brendan was accustomed to seeing such feedback on testing days, when heavy volume brought added strain to servers, and they accounted for this by increasing capacity. But this was different: there weren't any tests scheduled during the period. Instead, one of their own services was inadvertently DDOSing an endpoint, expecting a response; when one didn't arrive, it just kept making requests. They reworked this code to make a request once and simply wait for a response without trying again. In the future, they committed themselves to doing more in-person blitzes of new features, since issues like this only arise after multiple users use the app--something automated tests have trouble simulating. Links from this episode Nomadic Learning builds digital academies Launchpad Lab builds custom web and mobile applications for startups and established businesses
Episode Artwork

96. Incubating a Startup

Becky Jaimes is a product manager at Salesforce. She's interviewing Wesley Magness, the founder of ElectricSMS, and Melanie Plaza, the Head of Technology at AE Studio. ElectricSMS is a service to help consumers manage their various subscriptions, whether that's recurring orders of dog food or monthly boxes of snacks. ElectricSMS started as a project within AE Studio's incubator program, fitting in with their ethos to empower people through technology. AE Studio is a bootstrapped company that works with clients by offering development, data science, and design help to enable startups and enterprises to build technology products that helps humans, not profits. Their philosophy is to build products that treat their users well, so that the business can grow much more healthily than if you trick users into purchasing something they didn't mean to, or otherwise making it difficult for them to cancel. ElectricSMS is an example of how those principles came together in a collaborative partnership. For listeners interested in starting their own business, Wesley suggests finding a customer before working on something. You don't need an actual user to work with, but rather, a customer or industry who you know would benefit from what you built. With services like Heroku and Stripe it can be very easy to build an MVP from the ground up. Melanie concurs, and suggests talking to people who might want what you're making, and what their problems and needs are. Research what other solutions have and haven't worked. Startups can also reach out to AE Studio for direct consultation on taking their product to the next level, and potentially join their incubator program as well. Links from this episode ElectricSMS helps users manage their subscriptions through their phone Effective altruism movement advocates using evidence and reasoning to determine the most effective ways to benefit others
Episode Artwork

95. Intelligence Through Logging

Corey Martin, a customer solutions architect at Heroku, interviews Ariel Assaraf, the CEO of Coralogix, a platform that helps companies get a grasp on their log data. All too often, logs are considered as only a useful debugging tool. After receiving an alert around high resource usage or an elevated error rate, a developer might check their logs to see what caused the issue. But Ariel argues that this is too late to investigate a problem; by visualizing and alerting log data, you can figure out production problems before users encounter them. Metrics, in other words, are a lagging indicator, while logs are a real-time representation of how your code is really performing. One way to reconcile these two is to aggregate log data and funnel it into other long-term metric storage. This would allow you to see longer term trends. Ariel provides a scenario where log records appear in groups, such as a user purchasing a product, followed by an API call to Stripe, and concluding with an email notifying the user. A platform like Coralogix can automatically identify that the three logs arrive together within a certain time frame. If, for any reason, one of these steps fails to log, then a notification can be set up to notify the team to proactively investigate, rather than a customer writing in to report an error. For an organization to beginning using logs as time-series data, Ariel recommends three things. First, a unified log format, which could be something structured like JSON. These can be generated by a middleware service. Next, a shared understanding across teams on the severity with which to log a message. The final step is to set up an alerting policy; not only which types of alerts to create, but also where they go, such as Slack, email, or text message. After that, you can begin to incorporate your logs into your monitoring processes. Links from this episode Coralogix is an observability platform for logs, metrics, and security
Episode Artwork

94. Engineering Management

Anand Gurumurthi, a Director of Engineering at Salesforce, is joined by Marcus Blankenship, a senior manager at Heroku Salesforce on the Runtime Networking Team. Their topic for this episode is to provide career advice for experienced engineers looking to advance their career. There are several all too common scenarios individual contributors face, which Anand and Marcus discuss and offer their perspectives for. These include learning how to ask overcoming bias on your own work and figuring out how to better assess your strengths and weaknesses. In addition, Marcus and Anand discuss getting over the fear of asking for help. They agree that showing an active interest in finding out how a system works is a good way to show that you're engaged in your work and want to grow. In summary, confidence in the workplace is the key to getting what you want. Whether you're looking for a promotion or want to better understand a problem, you are in charge of starting those conversations. In situations where you're looking for guidance, ask for specific feedback from people who want to help you.
Episode Artwork

93. Conferences in a Virtual World

Chris Castle is a developer advocate at Heroku and Salesforce. He is joined by Carter Rabasa, the lead organizer of CascadiaJS, as well as Julián Duque, a developer advocate here at Salesforce/Heroku who organizes NodeConf and JSConf in Colombia. Carter shares his first experiences at a tech conference, finding it to be surprisingly intimate and a great community of well-intentioned web developers that wanted to learn. He was inspired to start CascadiaJS, a JavaScript conference situated in the Pacific Northwest. Over time, he realized that it's the people and the networking opportunities that really makes CascadiaJS special. When COVID-19 made it clear that in-person events would not happen for 2020, he and his team struggled to figure out how to put on an event that their community would love. It required them to imagine a future where software to support their vision didn't exist yet. They became certain that the event would need to learn how to be virtual for a long time. They accepted this challenge, and set to work building a conference model that they felt was interactive and immersive. There was just a tremendous excitement and enthusiasm to see if they could do something that hadn't been done yet. Of course, they stumbled in several ways; there were issues sending swag to customers, for example. Still, there are many reasons to keep the virtual conference format. For one, it's more accomodating for people with physical accessibility issues as well as attendees all over the world. There's more flexibility in the timing of events, where speakers can just play their sessions one after another; attendees can hop between different workshops and talks at the click of a mouse. Julián agrees that CascadiaJS' hybrid format of a recorded talk followed by a live Q&A was great for engagement, as speakers were chatting with viewers as their session played. Overall, Carter is excited at future conferences having a serious virtual component to them. Links from this episode CascadiaJS 2020 went virtual-only for the first time We Need Better Virtual Dev Conferences article NodeConf and JSConf in Colombia are just two events grappling with the pandemic
Episode Artwork

92. Strategies for Improving Your Mental Health

Dr. Mireille Reece is a practicing clinical psychologist and, along with Adam Stacoviak, editor-in-chief of the Changelog, they run Brain Science, a podcast exploring behavior change and mental health. Chris Castle, a Developer Advocate at Heroku, continues a previous conversation with them on how to take care of one's mental wellbeing. Their discussion centers around the neuroplasticity of the brain, how new habits can be created and formed. One of the best antidepressants is exercise. Adam advises that it's not necessarily about physical fitness, but rather that your brain really needs that motion. It can serve to provide one with a different perspective. As well, activating any of your senses--smell, touch, and so on--can bring on a calming effect. Other suggestions include meditating, which can bring on a greater sense of self-awareness, and journaling, which can be helpful in tracking your thoughts over time. Dr. Reece advises that keeping tracking of your moods can help hone in on the source of negative emotions. It's all about cause and effect. For example, if you eat a lot of fried foods, it might taste good, but ultimately, there are long term health affects associated with it. It's not that our actions are bad or good, but about recognizing the effects of them. Once we hone in on unfavorable consequences, we can start the process of adjusting our behaviors away from their sources. Links from this episode Brain Science is a podcast exploring the human brain to understand behavior change, habit formation & mental health Headspace and Calm are two apps which can help with mindfulness Day One is an app for journaling Essentialism is a book on "pursuing less" which Adam recommends
Episode Artwork

91. Destigmatizing Mental Health

Dr. Mireille Reece is a practicing clinical psychologist and, along with Adam Stacoviak, editor-in-chief of the Changelog, they run Brain Science, a podcast exploring behavior change and mental health. Chris Castle, a Developer Advocate at Heroku, is interviewing them to find out more about the stigma associated with mental health. There's an acknowledgement that while everyone at one point or another struggles with their mental health--be it through anxiety, depression, isolation, or stress--we, as a society, tend to be hesitant to discuss our struggles publicly. Dr. Reece posits that people view this as a weakness, one they're not willing to admit. There's a fear that if you reveal this part of yourself, you'll be rejected. Chris points out that mental health is not like physical health: if you break a finger, you can go to a doctor and get a splint. But if you have some mental anguish, it feels like your very identity is hurting, and Dr. Reece concurs that there's no "quick fix" to the problem. The first step, however, is to differentiate that how you hurt is not equivalent to who you are. You have to admit that you don't have the tools or skills to resolve the problem on your own, which will inevitably lead you to wanting to find a solution in a therapist. The dialog concludes with a recognition that there are many different types of therapy available, and it can be overwhelming to identify the one that works for you. The important thing to do is to find someone you can trust, and have a conversation with, because you'll be more willing to act on their advice. This might also mean seeing multiple therapists before discovering one that "fits." Adam posits that it can be helpful to imagine a future version of yourself as an end goal, from which you can begin to work towards through changing your habits and behaviors. Links from this episode Brain Science is a podcast exploring the human brain to understand behavior change, habit formation & mental health
Episode Artwork

90. Saving Lives at Scale: Part Two

Greg Nokes, Master Technical Architect at Heroku, is joined by Alex Broussard, the CTO of THINKMD. THINKMD is a technology company that's working to build next-generation clinical logic. The primary aim is to put healthcare tools in the hands of anyone, anywhere, but especially in places where healthcare access is limited. As Alex points out, the obvious challenge in such a platform is to optimize the application to work in low bandwidth settings. To work around this limitation, THINKMD designed their platform as a progressive web application, ensuring that, not matter what, it function as an "offline first" app. Data is collected and stored locally, and transmissions between the client and the server occur when Internet connectivity is restored. In addition to networking challenges, the functionality and the visual design of the app also has strict hardware limitations. The mobile devices running THINKMD are not smartphones, but rather older feature phones which lack touchscreens and keyboards. However, they're still very durable, with incredible battery life, and operate better under remote conditions. These phones run an operating system called KaiOS, which allows developers to build networked apps that run in Chrome browser environment. As well, THINKMD was founded by two doctors, which requires every update to the app to pass very rigorous clinical standards. Information that's presented cannot just have a good UX: it must also be accurate, as it's literally dealing with life or death situations. THINKMD's frontend runs on Vue.js. This choice was partially made because of Vuetify, which provides localization support, a component that's key to the app as it's used in over a dozen languages. By trusting how Vue and Vuetify support the look-and-feel of the app, Alex and his team can focus more on the backend data retrieval and delivery, including setting up duplicate servers across Asia and Africa to address latencies. For other teams who are building a multi-regional app targeted at low latency countries, Alex strongly suggests that you consider optimization techniques in advance of feature development. Links THINKMD's mission is to eliminate preventable deaths by increasing healthcare access via new and disruptive technologies KaiOS brings smartphone functionality to affordable devices
Episode Artwork

Special Episode: Scaling Businesses During a Pandemic

Greg Nokes is a Master Technical Architect at Heroku, and he's interviewing a returning guest, Ryan Townsend, the CTO of SHIFT Commerce. SHIFT Commerce is an e-commerce PaaS that provides an online space for businesses to host their websites and sell their goods. Their customers aren't exclusively virtual; some of them have brick-and-mortar shops which have had to shut down due to COIVD. As the volume of online ordering increased, some of these businesses noticed that their distribution centers couldn't keep up with the orders. This was due both to pent up demand as well as social distancing guidelines slowing the pace of operations. Working with these retailers, SHIFT Commerce came up with a rather simple solution: when an online order was placed, the platform would check to see whether a store closer to the customer already had the item they bought. If it did, then the customer would get their item shipped locally, rather than from the distribution center. This had several benefits: it saved the business money; it reduce emissions from vehicles driving all around the country; and it preserved the retail employees' jobs, as their tasks shifted from ringing up customers to selecting and packing shipments. Implementing the technical algorithm to perform this logic took just about a week; after that proof of concept, it took another four to six weeks to build a full fledged microservices that's completely API driven. The components used to design this were technologies that SHIFT Commerce had already invested in: Postgres, Redis, Apache Kafka, and so on. Ryan suggests that software companies always be prepared for unexpected changes, such as a new competitor entering the market. Having the flexibility to make decisions with agility helped SHIFT Commerce pivot and respond quickly to external changes, such as COVID. Links from this episode SHIFT Commerce delivers scalable e-commerce solutions Learn more about SHIFT Commerce in the Application Performance and Building SaaS on PaaS episode
Episode Artwork

89. Saving Lives at Scale: Part One

Greg Nokes, Master Technical Architect at Heroku, is joined by Meg McLaughlin, THINKMD's Director of Research and Implementation. THINKMD is a technology company that's working to build next-generation clinical logic. The primary aim is to put healthcare tools in the hands of anyone, anywhere, but especially in places where healthcare access is limited. The platform starts by guiding a user to provide some initial data about who they are. It then goes on to take the medical history of the person being assessed. By comparing a person's history, symptoms, and habits against the result of broader community data, THINKMD analyzes and visualizes that data to present information like the overall population and individual health. Using a system called syndromic surveillance, THINKMD can look at incoming data to assess epidemics, such as malaria or COVID. By looking at trends of data over time, such as people's temperatures, syndromic surveillance can help identify potential cases and clusters, ultimately assisting health systems to manage where to allocate testing, equipment, or treatments. THINKMD is operating in over 13 countries--primarily in Africa and Southeast Asia--requiring the platform to target a variety of languages and cultures. Tracking data is just one part of THINKMD's mission; the other portion is providing education and support for their on-site partners. Establishing campaigns to distribute vaccines and educating the populace on sanitary practices are just some of the challenges they face. They solve these problems by working closely to transfer knowledge to individuals who the community trusts. Links from this episode THINKMD's mission is to eliminate preventable deaths by increasing healthcare access via new and disruptive technologies
Episode Artwork

88. Monitoring Productivity through IoT

Corey Martin is a Customer Solutions Architect at Heroku. He's interviewing Brandon Stewart, the founder and project lead of GNAR, and Yuri Oliveira, one of its software engineers. GNAR is a software consultancy, and one of their projects involves building an Internet of Things solution for RMS, a freight transportation company. Internet of Things is a broad term used to describe any object that can connect to the Internet or communicate with other devices; popular examples include the Next Thermostat or Amazon Alexa. For RMS, Brandon and Yuri built a system to monitor trucks transporting shipping containers. Without an IoT infrastructure, truck drivers would communicate with their managers via radio signal, to get a sense of the optimal routes to take or the next task to focus on. With GNAR's IoT setup, the trucks communicate with their home base wirelessly, and there's no ambiguity over what to prioritize. Managers can also take a look at monthly data to track productivity, as well as individual drivers' performance. This gives them insights into both broad analytics and live behavior. The team at GNAR uses Heroku Postgres, Heroku Data for Redis, and Apache Kafka on Heroku to ingest, process, and store data. Placing their faith in Heroku's products lets them concentrate on building the unique aspects of their business, while offloading the DevOps responsibilities. For both Yuri and Brandon, the delight in working with IoT comes from using their abstract software development skills to affect changes in "the real world." Having that physical impact on a business' operations has been incredible to watch. Brandon believes that there are many industries that could benefit from incorporating IoT. He suggests that people interested in the space investigate industries, ask people questions, and see where opportunities can be found. Links from this episode GNAR is a software consultancy Learn more about how GNAR uses Heroku Discover how to run Apache Kafka on Heroku
Episode Artwork

87. Living with Landing

Jason Salaz is a member of the Heroku support team, and he's leading a conversation with Daniel Klein, a software engineer at Landing. Landing is a network of pre-furnished apartments that provides its users with a lease-free place to live for as many months as they need to. As remote work has becoming increasing necessary, the people who use Landing are able to live in any city they feel like across America. Aside from a monthly rent and annual membership, there are no other fees. In addition to furniture, the apartments have kitchen and bathroom basics, and maintenance is taken care of 24/7. Obviously, Landing has been affected by COVID and the lockdowns, which has limited people's ability to travel. With restrictions slowly easing, they've been seeing growth returning. In particular, Daniel's noted that retirees make up the most surprising portion of their customer base. Older individuals with no job and the freedom to travel can visit cities which they've always dreamed of seeing. Links from this episode Landing is a network of fully furnished apartments in cities all across the country
Episode Artwork

86. Innovations in Business Modeling

Becky Jaimes is a Product Manager at Salesforce, and she's interviewing Nick Frandsen, a co-founder of Dovetail. Dovetail is a company that helps startups grow into ambitious technology companies. They do this by providing an independent team of designers and programmers that will help the startup with growth hacking and marketing. The goal is to help them build their company and scale it into something much larger than where they currently are. In exchange, they take a piece of equity in the company, resulting in a longterm partnership. Employees at Dovetail both have a salary and a stake in each of the companies they work with. When it comes to working with clients, there are a set of factors Nick and his team relies on. First and foremost, they only work with startups that already have funding and a strong founding team. Leaders with a large domain expertise provides Dovetail with confidence that VCs have done their share of research in believing in a startup's future success. At the beginning of the relationship, they'll work directly with founders, and even work on hiring world class talent to achieve their goals. They'll set milestones together and Dovetail will step up to do the work wherever the startup might lack the experience or people power to complete them. Startups typically witness the benefit of the Dovetail relationship as more user engagement accrues, which helps to establish a longer term relationship. Yeah, we, we get quite a few. I mean, we have an investing framework where we sort of look for a range of different factors. I mean, some of them are the same things that I guess a lot of VCs are looking for. We're looking for a really strong founding team, people that have succeeded in the past, people that have been able to do a lot of interesting successful things in their past, and generally people that have sort of a lot of expertise in a certain area. One of the things that we really like is people that have a huge amount of domain expertise in something. We actually often like things that are not purely software, so something where there's either difficult barriers to entry or another thing that we like is sometimes we get founders coming to us with relatively obscure industries that we don't really know much about initially, but then we start looking into the industry and it turns out that it's enormous and that there are not tons of really modern companies operating in that industry. One of the things that I think is really important and actually often kind of under appreciated in our industry is just the importance of sales and marketing, especially in startups. The technology is really important, there's no doubt about it, but we see a lot of young companies that are strong in the technology side, but they really haven't put as much effort into how they're going to sell this product, how they're going to market it. It's kind of been an after thought. It's page seven of the pitch deck, but really without sales and marketing, you're not going to build the traction that you need. You're not going to get enough customers to get the feedback from them to raise further investment. I mean, in some ways, it's kind of annoying. I wish you could just build an awesome product and go from there. But that sales and marketing really is hugely important. Most of the companies in Dovetail's client list are FinTechs based out of Australia, but they have recently expanded to the U.S. Dovetail's business results eventually become aligned with the performance of the companies they work with, which positions them less as an agency. Their model requires a lot of discipline and investment, not just financially, but also strategically: both halves are continuously improving along the journey towards bigger growth. Links from this episode Dovetail is a full-service product development studio specializing in building digital products that scale
Episode Artwork

85. The New Definition of Frontend Development

Charlie Gleason is a designer and frontend developer at Heroku and Salesforce. He's invited Ben Vinegar, an experienced frontend developer and now manager at Sentry, to share his opinions on what frontend development means today. Way back in 2010, Ben understood that JavaScript, which wasn't taken all that seriously, had the potential to take a more significant part of the web development experience. At the time, Firebug had just been introduced, exposing developers to a debugging experience in the browser. From there, more JavaScript tools and frameworks began to proliferate. Just as Rails popularized the idea of an MVC, so too did Backbone, as well as introduce the concept of single page apps, leading to Angular, Ember, and eventually, React. For many people involved in (and observing) the JavaScript community, the pace of change induced a certain amount of uncertainty as to which framework developers should be learning. Ben empathizes with this frustration, but cautions that software development really hasn't changed in the last twenty years. Every time a brand new language or tool comes out that promises to revolutionize the industry, it's better to wait it out a year before even considering putting it into production. Better still, take a step back and ask how this new tool will make your app better for your users. When you approach software development as a way to solve people's problems, you become more pragmatic in your choices, and can work to solve real problems, rather than overoptimize or get distracted. Ben concludes by observing how designers have become much more technical over the last few years, with tools like Abstract introducing the concept of branches to design files, or the relationship between Figma and Sketch to actual code. Teams are no longer making mock-ups and handing them over to "real programmers" but actually building the components themselves, in reusable and shareable ways. Ultimately, he sees programming drifting more towards the full stack approach: in order to be able to build a good product, you need to understand how to implement features on a server, design it in a user friendly way, and apply JavaScript effectively to communicate with the backend and the browser.
Episode Artwork

84. Salesforce for Heroku Developers

Greg Nokes worked at Heroku right after it was acquired by Salesforce in December of 2010. He's joined in conversation by Chris De Gour, a Master Technical Architect at Salesforce, who has been working there since the acquisition. It's hard to imagine now, but when Salesforce and Heroku were both starting out, each company was introducing a radically different paradigm in how developers thought about their work. For Salesforce, it was about encouraging enterprise developers to embrace the Internet, and not need to worry about managing complex data schemes. For Heroku, they sought to make it as easy as possible to deploy applications, abstracting away the infrastructure and operations requirements. Salesforce was interested in Heroku precisely because they shared the same belief: that developers should concentrate on writing software, and leave the lower tier concerns to someone else. Now, the conversation has shifted. Companies who use Salesforce might not know how Heroku can help them. They've accumulated all of this data, about their customers or their business, and Heroku can provide them with an easy way to gain insights about that data. Perhaps they want to set up a workflow to pass sensitive information to other people. Salesforce can provide an SSO login system, sharing rules for the data, and other business logic; a simple app built in any mainstream language can run on Heroku to ingest that data. Greg and Chris both understand how levels of abstraction that cloud services provide can be perceived as "dangerous" models in several ways. By offloading concerns to other platforms, developers sometimes feel like they're not "really" developing; worse, they might believe that if they're not in total control of every aspect of the application, they'll eventually run into shortcomings. These fears are valid, but the industry as a whole has been embracing cloud services more and more as organizations realize that they can be most efficient when they focus on what matters to their core business. Links from this episode Trailhead is an online platform offering a variety of developer curriculums
Episode Artwork

83. SEO and Accessibility

Eric Chen is an engineer on Heroku's Ecosystem team. With him are Justin Abrams and Michael Rispoli, who run Cause of a Kind. Cause of a Kind helps organizations with their SEO; Justin engages with the brands on a marketing level, and Michael looks after their frontend development. The goal for SEO has evolved beyond just having the right metadata appear in search results. It's also about understanding how to make better business decisions, both through marketing strategies as well as organizational and technical planning to create products that serves consumer's needs. From the Internet's beginnings, SEO has been about helping search bots crawl sites through keywords. The thinking went that the better your metadata, the more likely your website was going to appear higher in search results. But these days, SEO is more about how users navigate sites. Justin and Michael explain how if you create a site with a user's experience in mind, the search bots and algorithms will rank you more favorably. You can use proper semantic HTML, provide accessibility through labels and aria tags, or define consistent URL routes; but you can also minimize frontend JavaScript dependencies to ensure that your page loads quickly. Organizations are investing more in frontend experiences more than ever before, from SPAs to even providing virtual and augmented reality experiences. Michael believes that developing sites with an SEO-first mindset almost inherently leads to a better product, because your performance and accessibility improvements will be noticeable to your users, even if you're trying to get better search ranks. In the end, both marketing needs--getting people to visit your site--and frontend development concerns--making sure people can use your site--are no longer two distinct issues. Links from this episode Lighthouse is an open-source, automated tool for improving the quality of web pages Cause of a Kind provides web marketing services to organizations Smashing Magazine and A List Apart are only magazines on frontend development BrightEdge gives marketers real-time research, recommendations, and rankings
Episode Artwork

Special Episode: Creativity and Connection in a Remote Workplace

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. Links from this episode Jamm provides video collaboration for remote teams
Episode Artwork

82. Processing Large Datasets with Python

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. Links from this episode "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
Episode Artwork

81. Exploring Technical Documentation

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. Links from this episode 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
Episode Artwork

80. Defining Operational Agility

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.
Episode Artwork

79. A Podcast about Podcasts

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. Links from this episode Adobe Audition, Zencastr, and Simplecast is some of the software used to produce the show This XKCD comic shows the importance of sanitizing inputs
Episode Artwork

78. Changing Culture Through Technology

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. Links from this episode 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
Episode Artwork

77. Voices of Native and Indigenous People in Tech

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. Links from this episode 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
Episode Artwork

76. The W3C and Standardizing the Web

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. Links from this episode 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.
Episode Artwork

Special Episode: Giving Back in Today's World

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. Links from this episode Softgiving is a platform for influencers to fundraise for their favorite causes The Givinga Foundation provides the data on charities for Softgiving
Episode Artwork

75. gRPC

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. Links from this episode 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.
Episode Artwork

Special Episode: Celebrating our Pride

Erin Allard is a Platform Support Engineer at Heroku, and she's leading a conversation with Jace Bryan (who works on the Customer Centric Engineering team at, Eric Routen (a family medicine resident in the New York area), and Bryan Vanderhoof (a manager on Heroku's runtime team). Each of these individuals come from different backgrounds, but they are united together in the larger LGBTQ community. After they came out, they sought ways to support other LGBTQ individuals who were not given the same opportunities as they were. Bryan focuses on helping homeless individuals, many of whom are children kicked out of their homes for being queer; Eric helps LGBTQ youth with job preparedness and substance abuse disorders; Jace shares their story of homelessness to college degree as a means of inspiring others to never give up. With respect to intersectionality, each of the speakers identifies that they are but a sliver of the communities they represent. It's important for them to acknowledge their own privileges, while at the same team being an ally for voices not at the table. Everyone goes through challenging experiences, but it's important to continue to show empathy towards others who need help too. One way to do that is to continue to volunteer, or at least, reach out to communities, and learn for yourself what problems they have. Uplifting those who don't look like or feel like you is one of the aims of Pride Month. Links HRC's Glossary of Terms helps you understand LGBTQ terminology The Night Ministry is an organization devoted to mitigating the suffering of homeless people in Chicago Ali Forney Center is an organization that helps people with job preparedness focuses on advancing empowerment through education and community for underrepresented individuals Power Of Us Hub is an online community for customers, certified partners, and staff Salesforce Pride 2020 provides items for purchase, with all proceeds donated to four different non-profit organizations around the globe
Episode Artwork

74. How Built a Community

Ben Halpern and Jess Lee are the co-founders of, an online community dedicating to helping the developer community communicate. They've been described as a social network for software developers, where anyone from novices to experts can create a blog post to share their ideas. They worked on the site for a long time as a side project, and after they launched, the unexpected and overwhelmingly positive responded they received encouraged them to turn it into their full-time job. Part of what makes so appealing is that it's been designed to be fast. The site is designed to take advantage of caching at POP centers, so that individuals around the world can access the content as quickly as possible. Since the project is also open sourced, they've been able to receive contributions from over 500 individuals, ensuring that no bug goes unseen. also considers community health to not just be essential to the business, but also a value woven into the company and the product. Their focus on education and strong moderation tooling has helped them build trust in their users. Users feel safe when the site actively minimizes aggressive language. The future of is shaped by the feedback they receive, but in many instances, they allow the community to thrive without too much administrative interference. Links from this episode is a community of software developers getting together to help one another out. CodeNewbie is a supportive, international community of people learning to code. DevDiscuss is a podcast from CodeNewbie that shares stories from people on their coding journey. CodeLand Conf is a community-first remote conference.
Episode Artwork

Special Episode: When Giving Back Saves 1000s of Jobs

Greg Nokes is a Master Technical Architect at Salesforce. His focus for this interview is on two members from MX Technologies, a fintech startup that helps financial institutions: Garrett Thornburg, an engineering team lead, and Brett Allred, its CPO. A consequence of COVID has been an increase in unemployment. In response to this, the U.S. Government came out with a paycheck protection program, or PPP, to lend money to small businesses to pay their staff. The program turned out to be incredibly popular, as banks and credit unions were inundated with applications to apply for these PPP funds. Many of these loans were processed by hand, and banks turned to MX Technologies to help process these faster. The technical challenges were daunting, and due to the urgency of the situation, the team at MX Technologies worked on a solution over three days to try and get an app out there. Choosing Heroku as a basis for the tech stack was not a difficult decision. They were able to code something up using Rails, and an automatically scalable Redis and database system. The only concern was that because they were working with financial data, they needed to ensure that whatever system they used met rigorous security guidelines. Naturally, Heroku did, and it even passed third-party penetration tests, instilling confidence in their use by the government. The MX team decided to open source their app and the Terraform scripts used to generate it because they want to make sure everyone is able to benefit from this essential program. Through their efforts, they've been able to help distribute $5 billion dollars, helping to save thousands of jobs and businesses. Links from this episode MX Technologies helps banks and customers manage their finances The open-sourced SBA Load Processing Portal powered by MX. The U.S. Small Business Administration is responsible for distributing loans
Episode Artwork

73. The Blockchain, Beyond Cryptocurrency

Owen Ou is an engineer at Heroku, and he is joined by two employees from AE Studio: Melanie Plaza, the Head of Technology, and Adam Hanna, an engineer. The conversation begins with a discussion of the tools used when developing with the blockchain in mind, including testing environments that mimic production systems like Ethereum. Developers in the blockchain community are constantly trying to lower the barriers to entry, and both Adam and Melanie agree that it's very easy to get started with the available tooling. The three take a step back from this and start talking about the origins of the blockchain and Bitcoin in particular, how it came about from a need for a decentralized system of privacy. The ultimate goal of the blockchain is to provide a repeatable and verifiable chain of anonymized information that cannot be tampered with. Each block in the blockchain is a cryptographic hash of all the data that came before it. Adam talks about how "mining" works--the incentives for people to provide computational resources to help verify the blockchain. Since all of this information is decentralized, no one can control or manipulate the history of the hashes. While cryptocurrencies have been used for nefarious activities in the past, Melanie is optimistic for its current and potential uses. Filecoin, for example, is a distributed file storage network on the blockchain. Residents of countries with draconian censorship laws rely on Ethereum to communicate safely with each other. Adam believes that a potential "second Internet" could arise for social conversations that's separate from the transactional, ad-driven one we currently use. Links from this episode AE Studio builds technology products that increase human agency Truffle allows you to spin up a development environment to compile and test your smart contracts on as if they were on the Ethereum network MetaMask is a browser extension which allows you to interact with your smart contracts and the Ethereum blockchain Merkle trees are the basis for the blockchain Overcoming Byzantine fault tolerance is one advantage of the blockchain Filecoin is an application of the blockchain for file storage
Episode Artwork

72. Designing with Lynn Fisher

Charlie Gleason, a designer and developer at Heroku, is joined by Lynn Fisher, a designer, CSS developer, and a software and design consultancy at &yet. Lynn went to school for Fine Arts, majoring in inter-media art. She found her unique perspective on art and design gave her a leg up in working with HTML and CSS projects in the mid-2000s, and from there, moved into working in frontend development. Her personal work has explored the creative possibilities of web design. A Single Div shows the incredible possibilities when drawing with a single div and CSS. The Food Place (from The Good Place), Top Chef Stats, and Dress David Rose (from Schitt's Creek) explore pop cultures through through minimal illustrations, and emphasize the flexibility of pure web development. US Flags [dot] Design is an exhaustive design guide to the flags of the United States, while Airport Codes demystifies the IATA three-letter airport code. Their discussion probes these projects, and how Lynn balances her work responsibilities with her creative (and time-consuming) artwork. Links from this episode A Single Div, a compilation of CSS drawing experiments Dress David Rose, which features illustrations of every shirt, sweater, and jacket David Rose wears on Schitt's Creek Lynn's portfolio refreshes, since 2007 The Food Place, which includes all the food, drink, and restaurants you remember from the television show “The Good Place” Airport Codes, which helps you to make sense of those three-letter airport codes US Flags [dot] Design, a design guide for the flags of the United States WhyAZ, a microsite of reasons it's awesome to live and work in Arizona Top Chef Stats, an exhaustive compilation of stats and facts across many seasons of Top Chef Hollywood Age Gap, which shows the age difference in years between movie love interests. Jen Simmons and Rachel Andrew provide guidance on using CSS Grid Heroku Hanafuda cards collaboration, and the award in Japan
Episode Artwork

Special Episode: Celebrating Technology, Asian Heritage, and Our Communities

Brian Chan and Vikram Sreedhar are Asian Americans and Anna Chan is British born Chinese and they are all working in various roles across Salesforce. Each of them grew up in different parts of the world and with varying interest in a career in tech. They discuss their journeys into a STEM career and ultimately how they ended up at Salesforce. One of the consequences of the COVID-19 situation has been an increase in the amount of racism aimed at members of various Asian communities. Because of these, each of the speakers has felt an increased responsibility in helping members of their community and others around them. This takes the form of donation, volunteering, or even just educating people on why their behavior could be interpreted as being hostile. What drives them in this work is the goal of raising awareness for these problems and helping improve the diversity for future generations entering tech. They conclude with some words of encouragement for people who want to start helping people in their community, whether they come from an Asian background or not. They also provide advice for those coming into tech on how to prepare themselves for success. Links from this episode FIRST Robotic inspires young people to be STEM leaders innovators by engaging them in exciting mentor-based programs that build technology skills Phenomenal Woman brings awareness to social causes Salesforce has a variety of equality groups of which Asiapacforce is just one.
Episode Artwork

71. Linking Data with Mulesoft

Becky Jaimes is a product manager at Salesforce interviewing Dejim Juang, Master Principal Solutions Engineer at Mulesoft. Recently, Dejim wrote an article describing how to connect Mulesoft with Heroku Postgres as a new data source. The main function of Mulesoft is to integrate with various SOA, SaaS, and APIs, and provide developers with a single integration point. Rather than writing entirely new data ingestion software from scratch, Mulesoft does the heavy lifting of connecting to data sources and responding back with the requested information. MuleSoft can be used to build integrations between Salesforce and applications outside of that ecosystem through a drag and drop interface. Some use cases where Mulesoft might not be appropriate include building a BPM tool or managing file transfers. Although Mulesoft certainly has these capabilities, they are too fragile and inefficient to be relied upon heavily. In terms of database connections, you can make RESTful API calls to Mulesoft and have it access information across all of your systems. This is especially useful if your customer data is located in one place and your software data is located somewhere else. Developers can also write their own code to manipulate the data from disparate sources. They can choose to share their project on the Anypoint Exchange, or continue to use it locally. Although Java is the primary language of choice, there are also scripting choices for JavaScript, Python, .Net, and Ruby. Mulesoft also comes with protections against reporting changes from underlying database migrations, as well as issues with connectivity. Links from this episode Dejim Juang's post on the connector between MuleSoft and Heroku Postgres and provide more information on working with Mulesoft
Episode Artwork

Special Episode: Active for Good

Charlie Gleason, a designer and developer at Heroku and Salesforce is in conversation with two members of the non-profit Active for Good: Troy Hickerson, its co-founder, and Luke Mysse, its managing director and brand strategist. Some years ago, Troy and Luke learned about Ready-to-Use Therapeutic Food, which is a powdered milk formula designed to provide vitamins and nutrients to malnourished children. Since such a simple product had the potential to help so many lives, they were inspired to find a way to increase its production and distribution. This led to them starting Active for Good. They knew that people weren't likely to make behavior changes unless there was a motivation. They decided that in order to help people get more fit, the distinguishing feature of their activity-tracking app would be to convert every minute of exercise into points, and those points into RUTF packets. Active for Good has two types of challenges: an open public challenge, where you and your friends can try to meet a goal over the course of 30 days; and company challenges, where a company can invest in their people to encourage more movement. The aim of the app is to minimize screen time, get active, and help real people in the process. Activities aren't limited to strenuous exercise, either; housework, meditation, and other positive physical movements are also considered. Everyone from individuals to high schools to corporations have found the project useful. Both Troy and Luke understand that changing your habits can be difficult. But they also know that it's just important to pick an activity and try it. Whether that's slowly gaining miles on a bike ride, or deciding which philanthropic project to get involved in, the most important thing is to just start doing it. Links from this episode: Active for Good helps people stay motivated and engaged by connecting their activity to a great cause. Ready-to-Use Therapeutic Food helps treat malnourished children by providing them with the nutrients they need A True Win-Win: How Being More Active Can Help Fight Malnutrition is our blog post where you can learn more about the Active for Good challenge.
Episode Artwork

70. Monitoring, Privacy, and Security in Public Cloud

Robert Blumen is a DevOps engineer at Salesforce, and he's interviewing Sean Porter, the CTO of Sensu, a cloud monitoring platform. Monitoring your infrastructure often looks like keeping track of the four golden signals: latency, throughput, error rate, and saturation. To that, Sean advocates identifying data specific catered to security and privacy. For example, with regards to intrusion detection, a company could track the rate at which unauthorized attempts are being made, and where they're coming from. This could signal potential weak spots in the system or software which malicious actors are probing. Armed with this data and analysis, one could reinforce their security. More broadly, intrusion detection is really about monitoring changes to your system's state. You could take a snapshot of your entire file systems, from permissions of folders to the individual bytes of each binary; by recording the information of a known "good" state, you can track any changes that are occurring. You would be able to identify the rate at which your servers are undergoing configuration drift, or be notified if key system software, such as ssh or ps, have been tampered with. Monitoring your security is about taking a proactive approach to observing any state change on a machine, not necessarily whether unauthorized ports are being sniffed. With regards to privacy, you could build some auditing functionality to ensure that you're not exposing any user information you shouldn't be. One approach might be to monitor whether numbers that look like a credit card are being accidentally showing up in your logs. It's also important to be mindful of compliance with regulations like GDPR. GDPR stipulates that users must give explicit permission for the ways in which you store and make use of their information. Sean points out that there are tracing systems which can track a user's movement from their browser navigation through each microservice they transparently access. Your monitoring system would want to keep an eye on these flows and ensure that every system is behaving appropriately. Links from this episode Sensu is a platform that automates monitoring workflows Sensu Go open source projects Sean Porter articles on DevOps Sean Porter technical blog Sean Porter talk on monitoring architecture patterns Google SRE book (free online version) CPU vulnerabilities like Spectre are a new breed of attack on public cloud systems Terraform offers tools for managing configuration drift
Episode Artwork

69. Designing a Better 2FA Mobile App

Chris Castle, a developer advocate at Salesforce, is joined by Evan Grim, a software architect at Salesforce responsible for the Salesforce Authenticator mobile app. Salesforce Authenticator is a component of a two-factor authentication flow. After a user signs in to their Salesforce organization, the mobile app will generate a secure code which is used to provide additional verification. This guarantees that even if a user's password is compromised, a hacker won't be able to login unless they have access to your phone, too. Experiencing a flow like this has become commonplace, with banks and other websites taking a security-first approach to their user experience. What's starting to change is the way these 2FA apps work. For example, Evan has built a flow where the Salesforce Authenticator uses geolocation to identify where you are. If you log in to a website from the same location enough times to establish a pattern, the app can send the security code automatically, without you needing to type anything in. Evan is very interested in exploring further trends where safety is not compromised for the sake of usability. For the remainder of the episode, Chris and Evan discuss the fundamentals of the technologies and systems used to build the app. Evan believes that keeping things simple is paramount to any software project. For many years, the Salesforce Authenticator backend was situated in one region, and it served them well. Now that the app has become more popular, they are considering the complexities of multi-region support, including sharding their Postgres database. Their trade-off for focusing on adoption over sophistication has paid off, as it often does. Now that their idea has been validated, they can plan to rearchitect their app to support increased volume from a growing security-conscious user base. Links from this episode Wikpedia's article on Multi-factor authentication Salesforce Authenticator is an intelligent two-factor authentication app Let's Encrypt provides free and automated SSL certificates for any website Securing the Web with Let's Encrypt podcast Heroku Postgres
Episode Artwork

68. Performance Tuning Critical Rendering Path

Charlie Gleason, a designer and developer at Heroku, is in conversation with Ben Harding, a developer at Raygun. Their conversation centers around a website's "critical render path," which are the steps in which HTML, CSS, and JavaScript are converted into pixels which a user actually interacts with in their browser. The fast these pixels are rendered, the better the experience which a user receives. Delays in website rendering can lead to an impact on one's business, as users are likely to leave slow sites; more often, it's an issue of accessibility, where users with slower connections should be able to visit any page they want to. Ben outlines four metrics that can be key to gathering information about how your website is performing. There's "time to first paint," which is the time it takes for a browser to render anything; there's "time to first contentful paint," which is the time it takes for the browser to render any content, like an image or text; there's load time, which is the time it takes for all of your assets--CSS, JavaScript, and fonts--to download; and there's "time to interactive," which is when a user can start engaging with a website, such as by clicking buttons or filling out a form. It's important to measure all of these stats first so that you can approach performance optimizations from a baseline of where you are, and where you want to be. There's plenty of low-hanging fruit when it comes to improving website rendering performance. You could try minifying and compressing your CSS, JavaScript, and images, so that the user's browser doesn't need to fetch large files. You can also implement techniques such as code splitting, which ensures that CSS and JavaScript is only loaded for the pages those styles or functions are needed on, rather than every single page on your site. You can load your assets asynchronously, so that the browser is not blocked on any one task. The important thing is to take a look at your starting metrics, and focus on tackling one of your problems until the load times are down to an acceptable range. Fine-tuning website performance is an iterative cycle: as more features are added, performance will degrade. Sometimes you can't optimize a website any further than you've already done, and that's okay. As long as you keep your user's perceived performance in mind, you can still get away with having spinners and splash screens, so long as they are receiving feedback and are aware that something is happening. Links from this epiode Critical rendering path DOM and CSSOM Lighthouse Webpack Parcel Uglify ImageOptim TinyPNG SVGO Media attributes for CSS files Async / defer for JavaScript Preloading / prefetching assets Heroku’sMalibu icon library SVG and sprite sheets Code splitting React Lazy and Suspense Visualising bundle sizes Tree shaking Raygun
Episode Artwork

Special Episode: Cybersecurity

Corey Martin, a customer solutions architect at Heroku, is in conversation with Jason Meller, the founder and CEO of Kolide, to talk about the future of enterprise security software. Kolide is a device monitoring software with an emphasis on its users. By and large, devices which are part of the Kolide fleet are free to operate unrestricted, whether that's downloading files or disabling firewalls. However, Kolide lets users know when they're engaging in potentially insecure behaviors, through Slack messages and OS notifications. It places the responsibility and trust for safety onto the user, rather than locking everything down. Jason came up with the idea for Kolide after working at GE. As an enormous enterprise company, GE had to ensure that its employees' devices were always secure, to prevent outside threats from infiltrating their network. While realizing the importance of keeping users safe, he disliked the invasiveness of existing tools, not to mention that their approaches hindered necessary applications and services employees used to be successful at their jobs. User focused security, which is what Kolide practices, starts with empathy. This comes about by visualizing the needs of people that are using the devices every day and trying to understand where risks might exist there, from the entire chain of users. Links from this episode Kolide is an infrastructure analytics company Osquery allows you to query your OS using an SQL syntax
Episode Artwork

67. Launching a Startup in a Regulated Industry

Corey Martin, a customer solutions architect at Heroku, is joined in conversation with Bryan Woods, the CTO of a platform called Rhino. Rhino is a simple CRUD app with an enormous responsibility. Typically, individuals need to pay thousands of dollars upfront when renting an apartment, to cover any damages and liabilities. Instead, Rhino charges renters--98% of whom are responsible and get their deposits back--a small monthly fee, and sends those payments directly to property holders. Landlords are protected and renters save money. Although the idea is easy to understand, the effort to launch the product required working with established regulations. One of the co-founders also had to license themselves as an agent who can sell insurance, just to be able to operate within city and state laws. Yet unlike many other startups, Bryan sees regulation as something to embrace, not skirt. By working with regulators, Rhino has been able to establish the rules for how they operate, as well as nearly guarantee a competitive advantage by being the only company operating in the insurance space in this way. As with many other startups, relying on established frameworks like Rails and stable platforms like Heroku have enabled Bryan and his team to focus on building a great product, not worry about implementation or uptime. Bryan also encourages other entrepreneurs working in heavily regulated spaces to trust in themselves and continue pushing through existing red tape. Rather than building something cheap and fast, truly revolutionary ideas will take time to convince others--particularly if legal requirements are already in place--but once you prove the idea you can become a leader in the field. Links from this episode Rhino replaces up-front security deposits with a small monthly payment
Episode Artwork

66. From Idea to Beta

Erin Allard, a Platform Support Engineer at Heroku, interviews Philippe Vanderstigel, who has launched several start-ups, most recently, RocketChart. RocketChart is a cash flow management and forecast software solution for businesses, and while it's been a success, it wasn't Philippe's first attempt. He's built products that managed online gaming subscriptions to selling sausages online. Some of these ideas worked, and others didn't. Undeterred, Philippe mocked up an image of what he envisioned a budgeting app to look like, and within twenty-four hours had hundreds of people expressing interest in an app that didn't exist. Philippe talks about the difficulties involved starting any business, namely raising funds and validating your ideas. Philippe very strongly believes that founders need to be directly engaged with their customers, especially in the early stages of the business. He personally responds to every message he receives, and asks direct questions to his users about what features they would like to see before his team spends time building them out. Of particular importance to Philippe is managing the expectations of his users. He is the only one working full-time on RocketChart; the other two employees, his friend Elie and brother Marc, have day jobs to pay their bills. What this results in is a very calculated and gradual acceptance of new users, which also receive direct one-on-one correspondence with Philippe. This also makes it easier to divide the workload, so that the three of them can continue building a sustainable business without taking outside funding. Links from this episode Philippe's post detailing how he validated a SaaS idea in one day to 150 beta signups Philippe's LinkedIn
Episode Artwork

Special Episode: Enabling a New Generation with Technology and Hawaiian Cultural Values

Blaine Kaho`onei is an Alliances Director for Heroku; he also sits on the board for Purple Mai`a, an online learning platform bringing technology skillsets to the native Hawaiian community. He's joined in conversation by David Pickett, a software developer and lead instructor with Purple Mai`a, as well as Jennifer Hooper, Heroku's Technical Product Marketing, Content, and Brand Director, who has also volunteered at Purple Mai`a. Blaine begins the dialog by talking about his interest in bringing together Hawaii's rich history of innovation and technological development with its indigenous culture. There aren't many economic opportunities for native families in Hawaii, nor are they programs designed to provide the youth with a valuable technical skill set. Most people with coding or design skills have felt the need to move away, furthering splintering the Hawaiian community. Blaine and David are keen to establish a tech hub in Hawaii. Blaine Kaho`onei is an Alliances Director for Heroku; he also sits on the board for Purple Mai`a, an educational non-profit, whose mission is to educate and inspire the native Hawaiian community through cultural, social and enterprise technologies. He's joined in conversation by David Pickett, a software developer and lead instructor with Purple Mai`a, as well as Jennifer Hooper, Heroku's Technical Product Marketing, Content, and Brand Director, who has also volunteered at Purple Mai`a. Blaine begins the dialog by talking about his interest in bringing together Hawaii's rich history of innovation and technological development with its indigenous culture. There aren't many economic opportunities for native families in Hawaii, nor are they programs designed to provide the youth with a valuable technical skill set. Most people with coding or design skills have felt the need to move away, furthering splintering the Hawaiian community. Blaine and David are keen to grow the tech hub in Hawaii. To accomplish that mission, Purple Mai`a's main focus is on middle school-aged students in classrooms. Volunteers and staff teach students on a range of topics, from coding and computer science fundamentals to user experience design and graphics design. In order to work towards assisting as many students as possible, David saw the need for incorporating a learning management system. Unable to find one that was centered on the student, they built their own platform called Haumana in 2017. They wanted it to be a tool for students to learn through what they're motivated about. This platform was in-use for in-person classes and is now being used for remote-only classes. Jennifer became involved in the program by volunteering her time answering questions on what a career in tech looks like. She also provides feedback on students' projects, and teaches them ways outside of the classroom to work on themselves, such as maintaining a LinkedIn profile. She has also provided insights into how Haumana can better achieve its goals with the critical perspective of an outside user. Many more classrooms are moving their curriculum online, whether by choice or circumstance. Purple Mai`a's ability to adapt, innovate, and embrace change on the fly have served Hawaiian teachers and students well over the years. Their emphasis on bridging Hawaiian culture with a valuable education provides them with a unique opportunity that they've ultimately succeeded at. Links from this episode Purple Mai`a is a technology education nonprofit whose mission is to teach coding and computer science to Native Hawaiian students.
Episode Artwork

65. Scaling Tech for Teachers

Sandy Lai is a customer solutions architect at Heroku, and she is interviewing two employees at Panorama Education: Ben Small, a software engineer, and Mitch Peabody, an engineering manager. Panorama is a platform designed to help educators, teachers, and principals, understand their students and their community by offering feedback surveys. As different schools have different technical expertise in their districts, Panorama caters its product to meet those needs. Different schools have different systems in place--sometimes as many as two or three different platforms in the same district--and Panorama built technology to pull that disparate data into one location to provide holistic (and individual) views into the results. The team at Panorama has found that schools largely rely on paper as they're extremely cautious about the data that is being shared on the kids in their classrooms. Security and privacy are top priorities for everyone at Panorama, from the CEO on down. They established a security working group to meet once a week and commit to making sure that security best practices are being taught and followed across the company. They also offer annual training for all employees on how to protect customer data. Panorama's currently tackling challenges around scaling, both from its customers and as the business itself hires more employees. There is a certain seasonality to their work, where the Spring and Fall months tend to be the most active months on the platform. There's also the issue of timing, where hundreds of thousands of users log in at around the same time. To help offset this, Panorama rolls feature changes out across timezones. That is, when the schools on America's East Coast are finished around 3pm, new updates are deployed for that region, a process that continues westward. This way, they're able to ensure reliability without disruption to the future time zones for their end-of-day rush. Links from this episode Panorama Education helps educators use data to support each student’s needs, and helps leaders build great schools. Panorama build their app using an event sourcing architecture
Episode Artwork

Special Episode: Books, Art, and Zombies: How to Survive in Today's World

Charlie Gleason, a designer at Heroku and Salesforce, sits down for a special conversation with Margaret Francis, the SVP of Platform Data Services. Their conversation is around the unavoidable topic of COVID-19, quarantines, and the disruptions to normal life around the world. Margaret starts the conversation by briefly contextualizing the event against two other catastrophes she experienced: the DotCom Crash of 2000, and the Global Financial Meltdown of 2008. While those two incidents had very real consequences to the tech, real estate, and banking industries, this current pandemic feels different, not the least of which being that every facet of life has been disrupted. Despite this, Margaret and Charlie keep their spirits up in a variety of ways. It's important to be radically honest with your family and coworkers about difficulties you're experiencing. You may just find that others have similar feelings, and sharing these thoughts can create stronger bonds of empathy. It's important too to try and find new ways every day to laugh, whether that's trying out a ridiculous haircut, or finding nonsensical videos online. Margaret advises trying to reconnect with a hobby you just haven't done in a long time. For her, that's reading, and she's recently picked up some of her favorite books that she knows will bring her joy. Trying out new activities can also lead you towards discovering new hobbies to enjoy, too, such as baking or sewing. We will one day be out of quarantine, and the pair pontificate on what that might mean for societies across the globe. Change seems inevitable, whether that means the MTA will continue its recent practice of scrubbing New York City subway cars clean, or the continued extension of safety nets that governments are establishing. No matter what, it's important to try and keep touch with friends and family, and to keep in mind that when this is all over, we will hug each other once again.
Episode Artwork

64. From Internship to Job Placement

Charlie Gleason, a designer and front end developer at Heroku, interviews Luis Alvarez. Luis is a data analyst intern at Heroku, and he got there through his involvement in Year Up. Year Up is akin to a bootcamp for young adults, divided into two phases. The first six months are a process of learning and development. Year Up pairs your interests with hands-on training in various subjects, such as data analytics, IT, and project management. There's consistent feedback from your classmates and you're constantly being evaluated on your progress. After this assessment, Year Up pairs students with companies. For example, students who excelled in data visualization courses will be matched to a company which requires that work. Luis carries the discussion by listing out the aspects of Year Up which surprised him. He appreciated the amount of time which his mentors at Heroku allotted for him, and was able to make the commute from San Jose to San Francisco largely because Year Up provides a monthly stipend for all of its students. Learning to anticipate his colleagues' needs was also necessary, as Luis' primary role was collating and representing data as graphs for others to make use of. Through the process, Luis was able to solidify his communication skills. In the end, Luis offers some advice for listeners who are keen to become future interns. He believes prospective Year Up students network should with as many people as they can, to ask for and suggest projects that coincide with their interests. Next, when it comes time to apply for jobs, he recommends an aggressive approach of applying to no less than three openings a day. As well, if you document the work you've been doing, you will find yourself with a portfolio which you can show to prospective employers. Links from this episode Year Up's mission is to close the Opportunity Divide by ensuring that young adults gain the skills, experiences, and support that will empower them to reach their potential through careers and higher education.
Episode Artwork

63. Streaming Music to Livestreamers

Julián Duque, a developer advocate at Heroku, interviews Nate Beck, the principal architect and founder of Pretzel Tech. Pretzel Tech is a company which has built Pretzel Rocks, a service that allows livestreamers to safely use licensed music. They do so by wrangling the needs of three different customers: broadcasters, who want to play fun music; record labels, which hold the rights to artists' music; and viewers, who want to play the same music at the same time as the broadcaster they are watching. The technical ability to stream music is not terribly difficult; but the challenge lies in fanning that out, to thousands of listeners, all at once. When a streamer logs in, 20,000 users might get notified and jump onto the stream all at once within seconds. Pretzel deals with these network spikes in several ways. Although their backend is a basic Rails app hosted on Heroku, they use Lambda to handle the broadcast, as they don't have a constant stream of traffic requiring many dynos. They use a CDN with plenty of POPs around the world to host the music, ensuring that it's fast and stable for users. Other difficulties including dealing with the music industry. For a single popular song, Nate needs to coordinates with 28 different companies to agree on a licensing rate. The industry also uses a standard called DDEX, which is an XML format to track metadata for artists, albums, and releases. This requires a custom pipeline to parse. Aside from that, Nate has nothing but praise for Twitch's API platform. The company is very community focused, with a public roadmap and excellent documentation for integratos. Its users often have plenty of positive feedback for Pretzel and other extensions. Pretzel's main focus right now is on ensuring the financial success for artists on the broadcasts of their music. Links from this episode Pretzel Rocks provides music for livestreamers 99 Lives is a record label which has a catalog stream-safe music Related: Pretzel Tech Handles Extreme Peaks in Demand with a Multi-Platform Architecture Centered on Heroku
Episode Artwork

62. Crowdsourcing Code Translation

Parker Phinney, creator of Interview Cake, continues his discussion from a previous episode with Julián Duque, a developer advocate at Heroku. Interview Cake provides different interview questions and programming exercise that adapt to the programming language that a candidate is working on. Since their coursework is essential to helping users succeed, they made an effort to ensure that the work was done accurately. First, they provided their entire course curriculum in Python, the programming language they were most familiar with. Then, they hired a team of language experts to convert those Python lessons into various other languages. Finally, they hired a second team of experts to review the work of the first team. This two-pass system allowed them to bootstrap expertise in almost a dozen different languages. Parker continues by discussing some of the challenges involved in this system, including keeping track of the work and managing the funds for various individuals. He also talks about various improvements they are making to the pipeline for their next iteration of content.
Episode Artwork

61. The Difference Engine

Join Charlie Gleason, a designer and developer at Heroku, as he interviews two people representing The Difference Engine: Kimberly Lowe-Williams, its founder and Executive Director, and Rachel Marro, a recent graduate. The Difference Engine is a Chicago-based nonprofit with the goal of empowering professionals from nontraditional backgrounds to launch their careers in tech. They do this through an apprenticeship web development program, mock technical interviews, and ways to highlight their relevant experience. Kimberley stresses that The Difference Engine expects applicants to have some familiarity with coding. The programs are designed to help adults with prior work experience navigate the often insular and nepotistic tech industry. One of her biggest tips is to encourage individuals to attend meet-ups, conferences, and other information sessions, to connect with others from similar backgrounds. Rachel concurs; it wasn't until she joined a few Slack groups that she realized her predicament was not unique, and it gave her more confidence in pursuing her career change into tech. Although just over three years old, The Difference Engine has already placed several apprentices into tech careers. One of Kimberley's goals for 2020 is to involve more corporate sponsorship, in two forms. First, The Difference Engine can guide tech companies in reevaluating their interview practices to eliminate unconscious biases. Second, employees at companies can volunteer their time to serve as mentors for apprentices. Links from this episode The Difference Engine is a non-profit transforming the lives of people through careers in tech Women in Technology and Chicago Tech Diversity Initiative are two communities which Rachel also participates in Get in touch with The Difference Engine to get involved
Episode Artwork

60. From Engineer to Entrepreneur

Erin Allard is a Platform Support Engineer at Heroku, and she's interviewing Ben Orenstein, one of the co-founders of Tuple. Screenshare was a popular pair programming app that was discontinued after being acquired by Slack. Finding no other alternative for this functionality, Ben and his friends built Tuple. Ben spent much of the early months of Tuple investigating pricing strategies, because he understood that the business wouldn't exist unless he could charge a reasonable price customers would be willing to pay. This process also reduced the risk of their efforts, knowing that they could burn through months of savings with the likely goal of being able to turn a profit. To that end, Tuple became completely bootstrapped and self-sufficient. Ben continues by pointing out that having a group of advisors has been instrumental to Tuple's success. These are friends and former colleagues who provide direct feedback, which allows Tuple to shape their own product roadmap based on real needs. He mentions the importance of being able to focus on the product and not the infrastructure as the main reason for choosing Heroku as the backend platform. Links from this episode Tuple is the app featured on this episode The Art of Product is Ben's podcast detailing his experiences running a business
Episode Artwork

59. All About the Cloud

Giorgio Regni, the co-founder and CTO of Scality, and Robert Blumen, a DevOps engineer at Salesforce, cover the basics of on prem, public cloud, private cloud and multi-cloud. The discussion covers business drivers, use cases, division of workloads, architecture, and networking concerns present in each of these categories. For enterprises, there is no "one cloud fits all" approach to building applications. The public cloud is more than an experimental platform for non-critical applications and unproven products - nor is the path of all computing migrating to its final home in the public cloud inevitable. Instead enterprises are arriving at the right mix of on premises private clouds which are increasingly containers providing APIs, and one or more public clouds. The motivations for selecting a cloud type can be vertical best-of-breed based on the offerings of a specific cloud provider, distributing peak capacity at lower cost, off site disaster recovery, or choosing a mix of vendors to avoid lock in. This mixed model works conceptually, but it also introduces issues around security, privacy, and the ability of enterprises to meet service level agreements. Increasingly, companies are grappling with integrating authentication solutions for these disparate locations. As a cloud storage provider, Giorgio provides his insights on how companies are building out these infrastructures and the tools they use to solve their problems. Links from this episode Scality is a company which develops storage software what is hybrid cloud eBook what is hybrid cloud according to MS Azure what is hybrid cloud according to Red Hat
Episode Artwork

58. Capturing and Analyzing Energy Usage Metrics

David Morganthaler, an Account Manager at Heroku, interviews two members from Kevala: Emmanuel Levijarvi, its engineering lead, and Teddy Ward, a software engineer. Kevala is building a one-to-one map of a community's energy grid, to identify how power is produced and model how it's consumed. They pull data from public sources and aggregate data to reliably predict when energy will be needed, and what an optimal price to pay for that energy generation. Balancing the exact amount of energy that people want alongside the amount that is being produced is an incredibly hard problem for the utility sector. If you don't produce enough, electronics won't work and vehicles can't be charged; if you produce too much, it's either wasted or has the potential to fry wiring and infrastructure. Kevala tries to monitor these figures by using machine learning on models they create, as well as tracking usage throughout the day. The Kevala engineers spend some time also talking about the dependencies used to achieve their goals. These range from hardware, like the IoT devices which consumers install or the access points they tap into to collect accurate data, as well as the software services which make up their app, like Auth0 and Postgres. Because of the unreliable nature of energy consumption, Heroku's autoscaling platform allows Kevala itself to spin up resources in a cost-effective manner. Links from this episode Kevala is a software company focused on analytics for the energy industry
Episode Artwork

57. Discussing Docker Containers and Kubernetes with a Docker Captain

Mike Mondragon interviews Bret Fisher, who works as a freelance DevOps/sysadmin consultant, and who also has the designation of being a Docker Captain. Docker Captain is a distinction that Docker awards select members of the community that are Docker experts and are passionate about sharing their Docker knowledge with others. To that end, Bret walks us through the history of how he became involved in Docker, and indeed, the history of Docker itself: the problems it tried to solve, and the way the codebase evolved to provide those solutions. Much of the conversation centers around the confusing terminology and processes present in the Docker ecosystem: when to use Docker Compose, the differences between running Docker locally and in production, and when to consider adopting Kubernetes. There are also various container runtimes which developers can make use of, and Bret touches on the characteristics of each as well. Bret looks towards the future of Docker, the company, as they recently sold off a portion of their enterprise-focused business. Docker is returning to its original intent to provide developers with better tooling to deploy and isolate their applications. He urges caution to teams ready to move wholeheartedly to Docker and instead focus on solutions that match their problems, not those of immense enterprise corporations. Links from this episode An explanation of a Docker Captain's role DevOps in Docker Talk is Bret's podcast Kata Containers, containerd, and cri-o are just some of the container runtimes out there Kelsey Hightower's Kubernetes: the hard way is a tutorial that walks you through setting up Kubernetes
Episode Artwork

56. Updating Legacy Code

Corey Martin is a Customer Solutions Architect at Heroku. On this episode of Code[ish], he’s interviewing Joe Leo, the founder and CEO of Def Method, a service-oriented software consultancy based out of New York City. The conversation begins with Leo providing his personal definition of legacy software as being any software that is not currently in the process of being written. He emphasizes that this does not mean something is immediately obsolete once it’s been written, but that at that point an individual or company must shift its energy and focus to maintenance and improvement. From there Martin and Leo move on to discussing how customers Def Method helps customers find solutions to their software issues. Whether a company is dealing with brownfield, greenfield or minefield software, Def Method attempts to help them determine how to deal with the problems they are faced with and how they can keep their system healthy as they continue to evolve. As Leo points out, no piece of software is future-proof or bug-free, so honesty and openness are required if a company wants to succeed. It’s Def Method’s goal to help its customers get to this point. The pair round out the conversation by talking about Leo’s recent book, The Well-Grounded Rubyist. The text, which was originally penned by Leo’s close friend David A. Black, is considered one of the most influential pieces of writing on Ruby and Leo was brought in to help co-author the third edition, which is published by Manning Publications. Leo views The Well-Grounded Rubyist as a text book with a philosophical bent and says that his primary focus was capturing the how the language has developed throughout its history and the very real tectonic shifts it has undergone during that time. Links from this episode Def Method is Joe Leo's consultancy that focuses on rescuing legacy software Def Method has also been featured as a Heroku Customer Success case study Code Climate is a code analyzer that runs as part of CI to ensure the quality of your code The Well-Grounded Rubyist is the Joe's book, available from Manning
Episode Artwork

55. When Side Projects Become Real

Mike Mondragon is the Lead Member of Technical Staff at Heroku. He's interviewing Ben Curtis, one of the co-founders of, which is an exception monitoring service for web developers. Curtis reminisces about how he came to Ruby through Rails during the early 2000s. Having already spent a few years as a web developer, he says he quickly fell in love with Ruby because everything he had learned, from templating and database abstraction layers, were built into its framework. The conversation then moves on to the founding of Honeybadger. Its genesis came when Curtis and one of the company’s other co-founders, Starre Horne, were working together at a startup building a Rails app and were using Airbrake to track exceptions. Frustrated by the lack of detail they were getting in their descriptions, they used Airbrake’s published code to create a new tool that would provide developers with a more thorough breakdown of what was happening. Initially, there was some pushback creating the project, but Curtis, a longtime proponent of open source, believes that Honeybadger’s development was in keeping with the ethos of open source. From there, the conversation moves on to a general discussion about the benefits of side projects both as a creative outlet and as a means to solve problems. Curtis said his approach to side projects has evolved over the years, and while he still does them for fun each project needs to be something he is willing to put his time and effort into regardless of whether other people will care. From there the interview moves on to discussion about burnout and the importance of a positive work-life balance, something which the entire team is very mindful of. Curtis concludes by saying that in the end the most important aspect of side projects is creating something that is your own. Links from this episode Curtis and his co-founders built FounderQuest is a podcast run by Curtis and his co-founders PackageBot is another of Ben's projects, which sends information about APT packages straight to Slack
Episode Artwork

54. Building a Business by Teaching Developers

Mike Mondragon is interviewing Geoffrey Grosenbach, the Director of Product Education at Hashicorp. Before that, he launched PeepCode in 2006, a platform for developers to share and sell screencasts of programing tutorials. Over the years, he was able to grow the company until its acquisition by Pluralsight; he describes what the experience was like. The conversation turns towards how to best learn new programming skills, after you've plateaued to being a "good" developer. Geoffrey suggests two things. First, writing about something you're working on is a good way to experience how you might express concepts to someone learning about them for the first time. He also recommends that developers step out of their comfort zone. For example, if you know how to git push to Heroku, perhaps you could try writing your own buildpack next. Towards the end of the episode, Mike and Geoffrey discuss the effects of attention, particularly around social media. The more you produce helpful content—whether that's an article, a video, or an open source project—you're bound to attract others. Finding that balance of joy and sanity can be a difficult one.
Episode Artwork

53. Scaling Telecommunications Data with a Service Mesh

Julián Duque is a senior developer advocate at the Heroku, and he's interviewing Luca Maraschi, a chief architect at TELUS Digital. TELUS is a large communications company in Canada, which processes a massive amount of data produced by millions of customers all across the country. One of their challenges, for example, was to design a single datastore which provided a consistent experience across online services and offline ones, such as call centers or brick-and-mortar stores. In the end, Luca describes how they were able to break apart the existing monolith in favor many different microservices. Luca notes that the data sources are not uniform; they can be coming from Excel files, Cassandra clusters, PostgresQL, MongoDB, and so on. He talks about the technologies they used to accomplish this feat, settling on GraphQL as a main component to the stack, as their services already act as edges in a graph. TELUS also makes use of Kuma and Kong, two relatively new projects. Luca finds new technologies to be not something to necessarily be afraid of, but rather, because they are often open source software, to make use of them as opportunities for driving the project's decision. The conversation wraps up with a discussion on the future of distributed systems. In the end, Luca believes that more responsibility for data manipulation should be placed on the client, rather the server identifying what it believes to be the "perfect" data set. This allows for greater flexibility, and opportunities for changing backend strategies as needs evolve, without user-facing disruption. Links from this episode Luca's talk at NodeConfEU 2019 titled "Scaling data from the lake to the mesh via OSS" Kuma (which ties microservices together) and Kong (which provides an API layer for them) are two technologies which Luca loves to use for TELUS' needs GraphQL helps TELUS with its goal for providing data as nodes in a graph
Episode Artwork

52. Building and Scaling a Heroku Add-on

Corey Martin is a Customer Solutions Architect at Heroku. He’s interviewing Adam McCrea, a software developer and the creator of Rails Autoscale, a Heroku add-on that allows developers to auto-scale their Ruby On Rails apps. They begin their conversation by talking about auto-scaling and how McCrea’s experience as a developer inspired him to create an application that would automatically handle the scaling of web and worker dynos. Having seen how valuable the initial app was for the company he worked for, McCrea set about turning his creation into a sellable product that could be used by other developers. If you’re working with more than one Heroku dyno, there’s a lot of guesswork involved in scaling resources. Rails Autoscale takes care of this problem, by automatically determining how many dynos an app needs, scaling them up when required and down when there is excess capacity, all in real-time. By using an app to take care of the process, McCrea knows that a vitally important process is taken care of regardless of fluctuations through the day or week, saving users money and providing peace of mind. The app also measures requests queuing time, as opposed to total response time, which provides a more accurate indication of real-time capacity requirements. Martin and McCrea round out their conversation by talking about McCrea’s experiences turning his application into a sellable product and how the Heroku Elements Marketplace has helped him get Rails Autoscaling into the hands of over 200 paying customers. McCrea says that as with everything there are trade-offs, but not having to worry about marketing Rails Autoscaling or handle billing have made the experience easily worthwhile for him. Finally, McCrea explains his attempts to further spread word about Rails Autoscaling, including engaging with the bootstrapper community on Twitter and attending conferences. Links from this episode Rails Autoscale, McCrea's add-on for Heroku How autoscaling works on Heroku Heroku's guide on how to build an add-on
Episode Artwork

51. Best Practices in Error Handling

Julián Duque is a senior developer advocate here at Heroku. He attended the NodeConf EU conference in Ireland, and met up with Ruben Bridgewater, a software architect and core Node.js contributor. Julián and Ruben go over the history of Node.js (now in its tenth year), as well as how Ruben became involved with the Node.js project. Ruben's focus on Node is providing its users with good developer experiences. As a consultant, he has seen how organizations frequently run into the same issues over and over. JavaScript is partly to blame here, as there are three different patterns for executing asynchronous logic: callbacks, promises, and the new async/await syntactic sugar. He'd like to help people avoid problems by strengthening their understanding around proper error handling. Ruben has several suggestions. First, he advises everyone to switch to using the async/await pattern of asynchronous code execution, which was introduced in Node 12. This allows errors to provide an async stack trace, which is more helpful in diagnosing errors than the obfuscated errors that come from promises. Second, he advises teams not to simply try-catch and rethrow errors. It's far more beneficial to abstract errors into individual classes (NotFoundError, NotPermittedError, etc), because it allows the programmer to identify immediately from the error name what went wrong. From this abstraction, Julián and Ruben discuss its role in logging strategies. By having your errors defined as distinct classes, you can place all sorts of "generic" information in them as properties, such as the status code. With no additional programming labor, this data can be exposed in the logs for additional analysis. Mostly, the best thing you can do is to think about errors while writing the code. For example, add tests for all the edge cases you may encounter. By investing more time upfront in the development process, you will save yourself from worries later on when the code hits production. Links from this episode Error handling: doing it right! is a talk Ruben gave at the Amsterdam JSNation Conference 2019 Let it crash is Julián's talk on error handling from NodeConf EU 2019
Episode Artwork

50. High Energy, Low Power: A Bluetooth Christmas Story

Armed with a Puck.js button and a bluetooth-powered power outlet, Chris Castle decided to make the Christmas lights magic. He dug into the code, Puck.js documentation, and seemingly oft-ignored specifications, eventually reverse engineering the whole thing. He built a site around it, showing how it worked, while learning more about design, SVG animation, and the occasional perils of the tools we choose to use. All so his nephew could press a button and see some magic happen. Joined by Heroku UX / UI lead Charlie Gleason, Chris delves into the project; digging into his rationale and process, the technical challenges he faced, and how kids are really great at user testing. Most of all, together they try and find a little of joy that can only be captured by kids at Christmas. Links from this episode Puck.js Bluetooth power outlet xkcd comic on standards Wireshark Slides for Keg dot io Sandpit.js and its terrible documentation Lynn Fisher Refactoring UI
Episode Artwork

49. Building Effective Distributed Teams

Anthony Mazzarella, a senior engineering manager at Heroku, is joined by Juan Pablo Buriticá the VP of engineering at Splice. Juan Pablo has spent the last decade building and running engineering teams across different industries. He believes in helping engineers find their role in fulfilling a business' higher level initiatives. Juan Pablo encourages teams to focus on planning just a little bit ahead of where you envision your business will be, in order to avoid much greater pains. This includes establishing communication channels that are agreed upon, even if your team is rather small. This way, there will be less ambiguity about where decisions are discussed, should your team grow in the future. In order to validate your successes, you need metrics to keep track of how your team is doing. Juan Pablo recommends four: how long it takes for a feature, from its first commit, to release to production; how long it takes to recover from an outage; how often you introduce new errors into production; and how often you're deploying code to production. By measuring these ideas, iterating on them, and introducing new metrics, the entire businesses—not just the engineers—can understand their role in the health of the company. Finally, the utmost priority for any business should be to satisfy their customers. It is worth paying someone else to solve any problem which deviates from this goal. That includes relying on Heroku for infrastructure and LaunchDarkly to handle feature flags. Tackling interesting technical problems is ultimately going to cost a company money anyway, as engineering time will be diverted away from helping a customer.
Episode Artwork

48. From NodeConf EU 2019

Alex Korzhikov is an engineer at ING Bank. He's at NodeConf to lead a workshop on using oclif, as well as working with classes and OOP in TypeScript. oclif is a command-line framework developed in TypeScript by Heroku, and ING is using several different tools built on oclif to communicate with each other. He talks with Julián about why they chose oclif, and how TypeScript has enabled them to build better systems faster. Tierney Cyren works as a developer advocate for Microsoft Azure. He's also the Chairperson of the Community Committee for Node.js. He's passionate about helping open source communities become more inclusive by helping them work on internationalization, documentation, and various governance needs. His talk is centered on four factors he's found are fundamental to growing a successful and healthy open source project. Chris Dickinson is building Entropic, a new package manager for Node.js. As opposed to npm, Entropic is comprised of federated hubs, ensuring that no single company or entity is responsible for all of the community's third-party packages. Previously, he worked on NPM itself, and knows first-hand how much a a distributed system is needed. Links from this episode oclif is an open source framework for building a command line interface (CLI) in Node.js Typescript: The Complete Developer's Guide is a recommended resource to master Typescript and build complex projects provides some guidance on building an empowered community Entropic is a distributed package manager for Node.js
Episode Artwork

47. Working with an Event-Driven Architecture

Robert Blumen is a Dev Ops engineer at Salesforce. He's interviewing Alexey Syomichev, a software engineering principle architect at Salesforce, with over 25 years of experience. Their conversation begins with what constitutes an event (an immutable record encoding something that happened to an app). They then move on to describe consumers of those events, whether they're internal to an app or external to other services and business departments. Finally, they discuss ways in which you can store that event, either in a database or a running event log. Databases and event logs each have their strengths and weaknesses, which Alexey enumerates. Event logs, for example, are easier to write to; but databases are easier to query for information. In general, Alexey believes that it can be important to organize your larger systems around an event log. The conversation concludes with a discussion on how to use an event log in practical ways. First, you'll need to decide the schema to use when representing an event. State transitions are another reality to consider. If multiple events representing the same action come in, you need to make sure that the event log is atomic. Finally, there's a question of precisely how many events to retain, how far back you store your application's state. Links from this episode OK Event Log (the architecture files episode 3) by Ian Varley Apache Kafka CQRS Pattern by Martin Fowler Event-driven architecture How Apache Kafka Inspired Our Platform Events Architecture by Alexey Syomichev About event-driven driven_architecture Protobufs and Apache Avro are two ways in which you can serialize an event.
Episode Artwork

46. Go at Heroku

Johnny Boursiquot is an SRE at Heroku, and joining him on this episode are Ed Muller (one-time Go language owner at Heroku), and Rishabh Wason, an engineer fresh out of university. Ed initiates the conversation by talking about how Heroku rolls out buildpack updates to users that are concurrent with Go releases. Heroku is a polyglot organization, and Go is being used as one of its four primary languages. It's finding its way into backends, microservices, and services which communicate with each other. Since many engineers at Heroku have experience in multiple languages, it's become essential for Go experts to teach others how to write idiomatic Go code. Part of this is done through the Go Design Guide, a living document that details the pros and cons of various ways to write Go logic. Ed in particular finds that pairing with other engineers on their issues has helped him understand a beginner's mindset, which he can then use to update internal documentation. Rishab also shares his strategies for how he learned Go, coming at it with prior experience in Java and Python. He provides a list of online resources which helped him. He also talks about some of the discrepancies he found in different code bases--for example, in their different dependency management styles. For him, the way in which he grew his understanding of the language was to ask targeted questions to reviewers in his pull request. Links from this episode Heroku's Go buildpack Futureforce places university graduates into internships and new jobs dep is a Go dependency management tool Go by Example is a popular place to see real-life Go examples Dave Cheney's blog covers a variety of Go topics
Episode Artwork

45. Illuminating Poetry with Technology

Casey Faist, Heroku's Python Buildpack Maintainer, sits down with Justin Kestler, the co-founder of LitCharts, and Devyn Gasperini, one of its full stack web developers. They discuss the genesis of the project, and how it's really an evolution of Web 2.0 sites such as SparkNotes. LitCharts differentiates itself by providing modern English translations of well-known literary works, as well as color highlighting and annotating content word by word. Through a clever use of hyperlinks, they can also cite intrareferential and interreferential materials. This has the end result of producing thorough analyses between 8,000 and 10,000 words. Much of the work developing LitCharts has centered around user experience and user feedback. The LitCharts team strives to not only provide a pleasing experience for the end user, but also a feature-rich interface for the writers providing annotations. Their end goal is to represent works of literature in unique ways, as well as literature that nobody else has covered. Links from this episode LitCharts takes a completely new approach to analyzing and explaining literature. LitChart Poetry Guides help you analyze and learn more about poetry.
Episode Artwork

44. GraphQL's Benefits and Costs

Owen Ou, an engineer at Heroku, is joined by Tanmai Gopal, the CEO of Hasura. They start their conversation by describing what GraphQL is, and what problems it set out to solve. GraphQL focuses on making data fetching easier, whether that client is a web browser or an API call. GraphQL provides one endpoint that can query all your application's domain logic. If your primary consumer of data is a front end application, then GraphQL is likely a good choice to use. The conversation continues with help on how to get started using GraphQL, and situations where GraphQL might not be useful. For example, if your data is not in JSON, or is in a binary format, it might not be a good fit. As well, depending on whether your application is a monolith or a set of microservices, how GraphQL incorporated varies, and can be difficult. Tanmai continues with his team's experience of incorporating GraphQL, the challenges they faced, and the improvements they noticed. Tanmai and Owen conclude by looking to the future of GraphQL. The language is very solid, but the spec is continuing to evolve with community feedback. Links from this episode is where you can learn all about GraphQL Awesome GraphQL provides a list of GraphQL tools offers GraphQL tutorials
Episode Artwork

43. The GitHub Student Developer Pack

Anupam Dagar is now a final-year undergraduate Computer Science student at Indian Institute of Information Technology, in Allahabad. He tells Joe Kutner, a software architect at Heroku, about how he first came across the GitHub Student Pack as a freshman. He needed a domain name, and one of his senior classmates advised him to take a look at the pack, which provides free tools for any student over the age of 13. With the Student Developer Pack, Anupam was able to build a project called HoxNox, a portfolio generator. He noticed that a lot of his friends were spending a lot of time perfecting their resumes on paper, so he decided to create a website that took the process digital. With an urge to keep honing his skills, HoxNox was his most ambitious project to date. With companies providing hosting and emailing services through the pack, he was able to build something that became quite successful. Anupam strongly encourages students to not get bogged down between deciding which language or framework to make use of when starting their projects. The fundamental principles of software engineering are applicable to all of them, including catching errors and writing maintainable code. He found it useful to just start with one new part of the tech stack to work on, before mastering it and moving on to something newer. It's also important to consider yourself as more than just your code. Talking to people and building a healthy community is just as important, perhaps moreso. Links from this episode Anupam's project HoxNox, a free and easy portfolio generator Python Django, the web framework he used The GitHub Student Developer Pack Heroku for GitHub Students
Episode Artwork

42. How to Prepare for Coding Interviews

Parker Phinney runs Interview Cake, a company with an online curriculum that prepares candidates for programming interviews. He's interviewed by Julián Duque, a developer advocate at Heroku. Interview Cake offers advice on communicating your intent, tips for navigating various decisions, and computer science concepts such as data structures and algorithm efficiency. Parker explains that he was inspired to create this site after helping a friend with her programming interview over the course of a weekend. He realized that while most coding bootcamps do teach eager students how to program, they don't do as well teaching soft skills, as well as more academic programming concepts. He built up his curriculum by partnering with bootcamps in San Francisco, teaching students directly, and assessing which parts of his lesson plan worked. Links from this episode Interview Cake teaches candidates how to solve programming interviews The Imposter's Handbook is a book recommended for a brief introduction to computer science terminology and concepts
Episode Artwork

41. Architecting Multi-Tenancy

Host Rubert Blumen is joined by Salesforce architect Ian Varley to discuss multi-tenancy. Their conversation covers how multi-tenancy differs from multi-user, popular architectures for multi-tenancy, why Salesforce uses a shared resource architecture, how Salesforce scales horizontally, the economics of a mix of small and large users, the importance of scaling down, scheduling, rate limiting and fairness, the threat model of a multi-tenant system, ensuring isolation between users, and technical challenges of migrating users between shards while maintaining availability and consistency. Links from this episode The Architecture Files #10: L33T M10y by Ian Varley Salesforce developer documentation on multi-tenancy ACM Queue Condos and Clouds by Pat Helland The Magic of Multi-Tenancy by Igal Levy
Episode Artwork

40. Operating Open Collective

François Hodierne is a lead engineer at Open Collective, and he's joined in conversation by Danielle Adams (the Node.js language owner at Heroku) and Becky Jaimes (the product manager for Heroku Data). Open Collective serves as a legal and banking entity for non-profit tech projects to raise donations and funds. All of Open Collective's repositories are open source, and they run a complete Node.js stack, via a GraphQL API on the backend and a Next.js frontend. As a core team of just three people, Open Collective relies on public contributions from its community. Recently, they've instituted a very successful bug bounty program, which uses labels to identify the amount of money an issue is worth. By assessing the difficult and urgency of an issue, they've been able to asynchronously communicate to others what they need to do and what they need to achieve to close the bug. Contributions have come in from developers all around the world, but after Open Collective's recent partnership with Open Source Community Africa, the main countries they've seen activity from were Nigeria and Kenya. Open Collective is hosted on Heroku, and they've found deployments by Git to be their most essential feature. They also rely on Heroku's metrics dashboards, which provides just the right amount of information. François notes that his key requirement for any hosting platform or JavaScript dependency is its adoption; the more popular a technology is, the more likely it is to be understood and the easier it becomes to on-board new contributors. Links from this episode OpenCollective on GitHub OpenCollective's blog post on their bounty program Open Source Community Africa
Episode Artwork

39. Evolving Alongside your Tech Stack

Chris Castle, a developer advocate at Heroku, leads the discussion with Tim Specht, the co-founder and CTO of Dubsmash, a video messaging application. Tim's involvement with software development stretches back over a decade, to the first evolution of smartphones, when memory management was essential and the new user experiences were being formed. It's become easier now to build applications, but the expectations on quality from users has also changed. For Tim, the two journeys are intertwined: it's not enough to have a depth-first approach to software development, and a baseline knowledge of how to make something computationally efficient aids programmers in building pleasing apps. The pivotal transition in Tim's understanding of how to build great software was getting better at prioritization. Allowing others to choose strategies that work best under the circumstances allows the entire project to move forward, rather than stalling endlessly to find the most optimal solution. It's important when making a technical decision to not stay committed to the path if it isn't working out. Any bottleneck has two solutions: either you brute force a solution at the expense of time and productivity, or you find a solution which is good enough. When it comes to building a product, Tim says that it's important to try and embed yourself into the news and events of your ecosystem as much as possible. Following authors on Medium or clicking through links on HackerNews not only tells you of what others are building; it also informs you of the new tools you have at your disposal. Of course, it's ill-advised to jump into a new library, language, or framework, without some evaluation and caution. But community adoption for something new--that is, other companies demonstrating success--is the best signifier for whether you should incorporate it as well.
Episode Artwork

38. Building with Web Components

Jamie White, a front-end engineer at Heroku, is in conversation with Ben Farrell, an award-winning designer working at Adobe. Ben has just written a book about web components, a way of designing websites that's been available roughly since 2013. Various polyfills and proprietary frameworks have achieved what web components is now trying to standardize: composable units of JavaScript and HTML that can be imported and reused across web applications. Ben goes over his personal experience with web components, and the history of the components themselves, starting with Polymer, which was essentially an experiment from Google. The library essentially recreated what various browser vendors wished web components would become. Eventually, the standards caught up, and now modern browsers don't need as many polyfills in order to accomplish the gains web components provides to developers. The key strength of web components for Ben is their reusability. For prototyping a UI element, he can write a block of code once, have it imported throughout a site, and continue to make modifications to that one piece of code as needs evolve. One such example of this is the web component called Shader Doodle, which abstracts a lot of WebGL "messiness" in favor of a simple interface. He is also working with others on the idea of constructable stylesheets as a means of also importing the same CSS rules and adopt them onto various web components. In the near future, projects like lit-HTML and lit-element will render incompatibilities between various frameworks, such as React and Angular obsolete. At their core, they will be built on web standards, which will mean easier interoperability, breaking down these barriers between them. Links from this episode Web Components in Action is Ben's book on designing, building, and deploying reusable web components from scratch Polymer is a set of libraries and tools to make developing web components easier lit-html and LitElement are additional tools to express HTML templating in JavaScript Shader Doodle is a web component for writing and rendering shaders Spectrum employs constructable stylesheets to provide a design framework Lightning Web Components is Salesforce's bundle of web components for its platform Web Components Essentials is a book by Cory Rylan to help teach the core fundamentals of web components Polymer's Slack workspace is available as a resource for more information
Episode Artwork

37. Bonus: Organizing a Memorable Tech Conference

Leah organizes both RustConf and EmberConf, and has been organizing tech conferences for well over a decade. She talks about some of the lessons she's learned in building inclusivity and accessibility into the conferences, outside of the technical talks. Childcare, for example, is one feature she's introduced that has had a positive effect on both parents and children. Suddenly, workers don't need to fret between networking with their peers and finding quality day care. Leah cautions that the first few years she offered this space, there weren't many enrollments, primarily because attendees didn't know that the option was available. But year after year, more parents are participating. As ideas on gender are evolving, Leah has experimented with applying pronoun usage onto badges. At first, she made this mandatory, requiring attendees to provide their preferred pronoun while registering for the conference. She thought that this would help normalize the terminology, but she says her opinion has changed after speaking to several people. Instead, she provides pronoun stickers to attendees when they collect their badges at the conference. Some smaller opportunities, like building fitness activities into the schedule, also helps attendees maintain their routine and connect with other conference-goers in ways they might not otherwise be able to. Links from this episode Leah's book, Event Driven, is all about running tech conferences Leah's previous podcast, 35. Bringing Open Source to Work
Episode Artwork

36. Supporting Open Source through Open Collective

Chris Castle, developer advocate at Heroku, sits down with several individuals working towards making the lives of open source maintainers a little easier: Josh Simmons is the VP of the Open Source Initiative and a Senior Open Source Strategist at Salesforce; Joe Kutner works on open source programs at Heroku; and Pia Mancini, is the co-founder and CEO of Open Collective, a platform that gets funding from companies and individuals and disperses it to the open source projects they use, without those projects needing to have their own business bank account. The issues involved with financing open source projects are two-fold: first, there's the challenge of actually collecting money from corporations profiting off of open source developers' free time; and after that, actually sorting out how to disperse these funds to contributors. Pia provides an example of the struggle of a Ukranian developer invoicing a company and receiving compensation from a U.S. bank account. Open Collective's goal is to solve both of these problems, by connecting funders with projects, and handling all of the messy paperwork involved as a consequence. Josh and Joe both point out that the strategy isn't just to provide a monthly donation charge, either. Funds can be allocated to support bug bounty programs, where security experts not necessarily involved in a project can participate and receive pay-outs. That's necessary work that a maintainer might not necessarily think about organizing, and which definitely benefits the project. The Open Collective provides two other services within its umbrella. BackYourStack is a website which will scan the public repositories of a GitHub organization, and identifies which dependencies are part of the collective, such that companies can fairly sponsor projects they didn't even know they depended on. Gift Cards is an opportunity for companies to provide gift cards to their engineers, who then in turn give those to maintainers who they acknowledge as being tremendously helpful. This places the decision making for sponsorship on the developers who most often interact with other open source developers . The episode concludes with a foray into issues beyond financing, specifically a maintainers' well being. Open source isn't just about creating software; you've got to also delve into issues, identify what's important, have discussions, and sometimes, fend off abuse from users' unreasonable expectations. Josh explicitly mentions Open Sourcing Mental Illness as a resource for assisting individuals experiencing burnout. The Open Collective is also exploring ways in which to assist maintainers with tasks such as triaging issues or updating documentation. Links from this episode Open Collective accepts corporate sponsorships and distributes funds to open source communities Open Source Initiative has been promoted adoption of open source technologies since 1998 BackYourStack scans your organization and GitHub, and tells you which projects are seeking funding throughout Open Collective Gift Cards from the Open Collective allow employees of companies using open source projects to support maintainers directly Open Sourcing Mental Illness, provides resources to support mental wellness in the tech and open source communities
Episode Artwork

35. Bringing Open Source to Work

Leah Silber is the CEO of Tilde, and she and her company have been involved in various open source projects over the years, from jQuery and Rails, to Ember and Rust. Her belief is that open source work is more than just the programming: it's also corralling issues, finding the right people for the right problems, and more "real world" tasks such as setting up events and conferences. Because of this, she doesn't believe there's a strong delineation between "skills for a business" and "skills for a project." Allowing employees to explore new roles in projects that they love helps their skill set grow, and those skills can in turn make them better employees. The key to this dynamic is demonstrating OSS values at work. When you treat someone's contributions to projects as an essential parts of their role, there isn't a direct correlation with the relationship between the company and the project. You are investing in the person and the technology, and in the long run, this will benefit the business. Leah also believes that it's important for open source communities to not have a single point of failure by way of a single company being invested in a technology. If, for some reason, a business' needs shift away from a particular language or tool, the last thing anyone would want would be for an open source project to wither as a result of it. This is another reason why a company backing an open source project should be much more receptive of accepting contributions for contributors. Finally, by having companies more involved in open source projects via their employees, they can direct and guide the project to satisfy their own business needs. The two entities--company and project--can discuss their needs and arrive at solutions together, rather than introducing fragmentation. What's good for a company may also be good for the community, and what's more, the community may have more stable and reliable implementations for any single company's ideas. Links from this episode Event Driven is Leah's book about running memorable tech conferences
Episode Artwork

34. An Introduction to Rust

You couldn't find a more perfect pair of guests to talk about Rust than Carol Nichols and Jake Goulding. Carol and Jake write books that teach Rust, maintain websites that allow users to run Rust samples, record videos about Rust, and also manage the Rust Belt Rust conference, where Rust developers congregate in the Rust Belt region of America. Carol has a background in Ruby, and always sought to eke out more performance and less memory consumption. Jake has a background in C, but recognizes that it places a heavy burden on a programmer to be mindful of memory leaks and segmentation faults. Rust is a fantastic programming language from Mozilla. It has a much simpler and intuitive syntax than C, the compiler is optimized to ensure that you are writing memory-safe code, and as a result, it produces executables that run much more quickly (and require less resource consumption) than a dynamic language like Ruby. Carol and Jake delve into how the Rust compiler does this, primarily by aggressively freeing memory and forbidding developers from interactions with dereferenced objects. To newcomers, Rust seems like a forboding language, but Carol and Jake believe that Rust's emphasis on terrific documentation and error messages help guide newbies and veterans alike into writing safer and faster code. Several large companies see the benefits of Rust and are writing it in production, such as Mozilla, Google, Facebook, and Amazon. Heroku even has an unofficial buildpack for serving Rust applications, and Carol notes that in one of her projects she's paying more for log storage than for dyno consumption, due to how efficiently Rust uses memory. Rust has an ecosystem-first approach to language design (rather than placing everything into the standard library), which has fostered a largely collaborative open source community. Carol and Jake advise, however, that the language is still evolving, and they don't recommend rewriting all your functional business logic into Rust just yet. The two conclude by providing many resources on getting started with Rust in the form of books, videos, and coding challenges. Links from this episode Many resources for learning Rust were mentioned in this episode: For books, you can get started by reading The Rust Programming Language Book or Programming Rust For hands-on coding examples, the Rust Playground allows you to run snippets of Rust code; Rust by Example shows common programming problems solved through Rust implementations; the Rust Cookbook offers slightly longer code samples; and both Rustlings and have interactive tutorials Rust in Motion is a video series Carol and Jake are producing to introduce developers to Rust The Rust Belt Rust conference is where Rust developers and enthusiasts from around the world will gather to discuss production Rust usage, best practices, and what’s next for Rust. is where Rust packages reside Rust is in production at Mozilla, Amazon, and Google
Episode Artwork

33. GopherCon 2019 Spotlight, Part 2

Aaron Schlesinger is the core maintainer on Athens, an open source on-prem module proxy. He walks through the history of packages and modules in Go, and introduces how Athens satisfies the needs of developers. Go modules allow you to serve up a Go project's dependencies via an API; Athens implements that API--and integrates with other implementations of the API as well--to simplify dependency management, no matter where the code is stored. Beyang Liu is the CTO and co-founder of Sourcegraph, a company that focuses on developer tools. They use Go to build high-performance code search, code intelligence, and jump to def functionality that works across repository boundaries and across entire code bases. Their role at GopherCon 2019 is to live blog all of the talks for interested parties who were not able to physically attend the conference. Liz Rice is a technology evangelist with Aqua Security. It's a container security company, and she came to GopherCon to teach a workshop that introduced people to the concepts behind containers. She also recently became a Google developer expert in Go, which certifies her as someone creating interesting content that the community can look towards for education and inspiration. Johnny Boursiquot is an SRE at Heroku, and a long time gopher. He gave the closing keynote at GopherCon, and his singular focus is on ensuring that the Go community is truly diverse and welcoming to new members. Every year, new developers attend GopherCon, and he wants to encourage veterans to embrace this growth as a positive change. He also provides a wealth of resources on listeners who are brand new to Go and eager to learn more about it. Links from this episode Athens Project is a proxy server for the Go modules download API Several resources for newcomers to Go include: A Tour of Go Go by Example Go Bridge workshops Aaron Schlesinger's talk, "The Athens Project" Johnny Boursiquot's closing keynote, "What Got Us Here, Won't Get Us There"
Episode Artwork

32. GopherCon 2019 Spotlight, Part 1

Chris Castle recently attended GopherCon 2019 in San Diego, and captured small conversations from many different Go community members. In Part One of a two-part episode, he had several conversations with GopherCon speakers about what they were building. Nick Gerakines is the Director of Software Engineering at Mattel, the toy company. Mattel has several toys with Internet connectivity, and Go is the primary language used for all of their connected products, whether it's to support authentication and parental controls, or providing product catalog and product instance information. A lot of core gameplay mechanics, such as the number of "miles" a car has ridden on a track, are also transmitted and reported through Go services. Robert Ross works at FireHydrant. They're using Go for their Kubernetes integration and internal developer tools for local development. For example, they are able to build Docker Compose files on the fly. His favorite aspect about the language is that it can build a portable (and performant!) binary with very few lines of code. Jessica Lucci is an infrastructure engineer at GitHub. Her interest in Go is catered towards establishing some standardizations beyond simple code formatting. For example, with the recent introduction of Go modules, devising a system around versioning third-party libraries is an interesting problem, particularly when it comes to pinning versions for consistency or updating versions in the event of a CVE. Tim Raymond works for Gopher Guides, and conducted a training session on testing your Go code. His favorite aspect of GopherCon is its community, where new and old friends meet to share their interests. Jay McGavren is the author of Head First Go, a programming book designed to teach programmers about how to be effective with Go. It will take Go beginners from basic language features all the way to coding a simple web app. Carolyn Van Slyck works for Microsoft, and she's used Go to design her perfect CLI. By focusing on the developer experience, she was not only able to abstract away some of the harder tasks which a user might rely upon piping several commands together into one, but she also isolated some of the CLI-specific aspects, such as argument parsing, for future developers to feel more confident when contributing to the project. Links from this episode The Mattel Hot Wheels id toy is powered by Go services Modules are a newer system of dependency management for Go Head First Go is a programming tutorial for Go, written by Jay McGavren and published by O'Reilly Media Gopher Guides leads Go workshops for interested individuals Jessica Lucci's talk, "You Can't Go Your Own Way" Tim Raymond's lightning talk, "Parsing Expression Grammar" Jay McGavren's talk, "Teaching Tech", on effectively teaching programming Carolyn Van Slyck's talk, "Design Command-Line Tools People Love"
Episode Artwork

31. Building Docker images with Cloud Native Buildpacks

Joe Kutner, an engineer at Heroku, leads the discussion on Cloud Native Buildpacks with Stephen Levine (engineer at Pivotal), Emily Casey (engineer at Pivotal), Ben Hale (steward of the Java Buildpack), and Terence Lee (engineer at Heroku). All of them are involved in overseeing the CNB project, and have used the technology in production at their companies. At its core, CNBs are an OCI-compliant alternative to Dockerfiles, except the container is built without very much developer interaction. By analyzing source code, CNB is able to determine the base image to start from, as well as which steps to undertake in order to ensure that an application runs correctly. It's a similar logical process to the way in which Heroku's regular buildpacks operate: one Git push command is all that Heroku needs to generate a slug of your application, including fetching any dependencies or managing assets. A Buildpack provides you with consistency by keeping your dependencies and base image up-to-date to the latest standards. It also doesn't require the average application developer to also be an expert on everything. Rather than needing to understand all of the Unix-y commands necessary to compose an application, or knowing when a particular component has a CVE, a developer's chief concern concern is to continue building their app as usual, and CNB will handle all of the other components necessary to make a deployable container. The aim for CNBs was to make development easier for individual developers, as well as those at large enterprises. Terrance and Ben in particular know that the value of the buildpacks come from five years of production experience. Regular applications have benefitted from buildpacks, and the ecosystem around those had grown to the point where they could take what they'd learned and apply them to container images as well. The episode concludes with a look towards the future of CNBs. As all of the APIs and tooling are open source, groups can also design CNBs for any language and framework they wish to containerize. The project recently entered beta, and, despite the positive reaction, there are still some changes that need to be made with regards to how changes to buildpacks are applied. There are processes for community members to be involved, and multiple forums for communicating with the CNB leadership team. Links from this episode is where you can go to learn more about Cloud Native Buildpacks Discussion for proposals to CNB happens on GitHub on GitHub There's a Slack workspace where developers and users congregate
Episode Artwork

30. The Infrastructure Behind Salesforce's Chatbots

As part of its product suite to automate a business' needs, Salesforce offers a Live Agent product, whose central component is a chatbot that can respond to a user's inquiries on the web or other messaging platforms, such as Facebook or SMS. A key design requirement of the chatbot is to be able to simulate human interaction by responding quickly. For an engineering team of eight, that means being able to offload as much operational responsibility as possible to Heroku's platform. Salesforce's customers exist around the world, from Europe to Asia to the Americas. Heroku provide multiregional offerings for its dynos and databases that don't require too much administration or configuration. The benefits of not needing to define roles or specifications further simplifies the chatbot team's own architectural decision to design it as a collection of microservices. Furthermore, the chatbot team uses Terraform to define the infrastructure requirements of their application. By predefining the necessary add-ons, data services, and private spaces for every application, they are able to quickly spin up new external services whenever necessary. Links from this episode Salesforce's Live Chat is powered by chatbots to reply to users' issues in real-time. Heroku buildpacks are open source packages which turn an application's source code into an executable slug. The Salesforce chatbot team built their own customized buildpacks to support their unique needs. Terraform offers a provider that integrates with Heroku
Episode Artwork

29. Technology and Art

Cory Haber is the VP of Technology for Furnished Quarters, a global corporate housing company. But he's also an educated painter. He's interviewed by Erin Allard, a Platform Support Engineer at Heroku, to delve into the effect technology has had on art, and vice versa. For Cory, art is about the intent of the artist; it's a moot point to ask whether anything a computer produces can be considered art. In the end, a human has trained an AI or written the software, and the computer becomes a tool, similar to a camera or a pen. Engaging in artist practices allows Cory to take a break from the purely logical examinations which programming requires of him. To some, it may be seen as procrastination, but he believes that the best way to solve a problem is to allow your mind to wander of. That's what his current painting practices allows him to do. At the same time, he also follows along on the generative art movement, which takes place primarily on Twitter. There, artists and programmers share their programs that generate art that can be represented on screens or canvases. The history of generative art goes back to the 60s. For individuals curious to learn more about this practice, he recommends the Processing programming language. Similar to a Jupyter notebook, it's a part-framework, part-application hybrid that works in generating visual arts. He also encourages individuals with no artistic background to just start taking classes on painting or music. No one knows everything about programming when they first start; they learn the skill and become better at it the more time they invest. Art is created under a similar focus. Links from this episode Cory has compiled a list of resources with more information on the intersection of technology and art: Early Generative Artists Vera Molnar Lillian Schwartz Ken Knowlton Frieder Nake Georg Nees Michael Noll Current Generative Artists and Plotter Artists Tyler Hobbs Paul Rickards Benjamin Kovach Anders Hoff Matt Deslauriers Manuel Gamboa Naon Casey Reas (Co-Founder of Processing) John Maeda Jared Tarbell AI Artists Robbie Barrat Mario Klingemann Frameworks Processing openFrameworks Learning Resources Art Nome The Coding Train Daniel Shiffman Books on Generative Art Manohar Vanga Influential Artists Piet Mondrian Sol Lewitt Hilma af Klint Kasimir Malevich Wassily Kandinsky Joseph Albers
Episode Artwork

28. Effective Leadership Development

Trey starts the conversation with Shirley by noting the difference between being a manager and being a leader. Managers are a framework for discussing pay, onboarding and offboarding, HR interactions, and so forth. Leadership is about inspiring others to unite together to work behind a purpose. Any IC, for example, can be a leader for just a handful of his teammates. Being a good leader means knowing what's important, conveying that to someone else, and executing on it. To do that, Trey emphasizes that a foundation of psychological safety is essential. Allowing people to speak up when they disagree with an issue, or admitting your faults when you've made a mistake, is an incredible method of breaking down barriers between people and fostering a culture of truth. Fostering individual growth is also a good strategy, as people generally want to continue improving, whether it's learning a new programming language or a new technical system they're curious about. Removing obstacles to people achieving their goals is key as a leader. Shirley notes that the role of a leader requires an immense amount of mental and emotional energy, as your concerns are not just your own, but also those of the people who rely on you. Trey responds by emphasizing health as an important priority that's often neglected. Individuals will take better care of their pets than themselves. By demonstrating that he is not infallible, by taking vacations, encouraging exercise, or ensuring enough hours of sleep, his team in response understands that taking breaks is a good decision, not a dangerous one. Finally, communication is always necessary. If there are too many distractions that prevent you from accomplishing an objective, you should tell your team you'll need some quiet time, rather than silently disappear. If you're concerned about a path a company is embarking on, you should tell a leader you feel comfortable talking with. Communication breeds trust, and that's the foundation of any successful relationship. Links from this episode Trey recommends several books on effective leadership: "Chasing excellence" "The Score will Take Care of Itself" "Extreme Ownership" "Dichotomy of Leadership" "Drive" "How to Win Friends" "Crucial Conversations "Slack"
Episode Artwork

27. Behind the Brand with Heroku's Lead Designer

Design is at the very core of Heroku, influencing every aspect of the brand and the platform. Join Vikram Rana, product marketing and developer advocacy lead at Heroku, as he chats with Heroku’s head of brand design and front-end developer Charlie Gleason on his role—covering his history and background, what it’s like to work at Heroku, and how he handles being a custodian for a brand he loves. From tooling, to teamwork, to the ethos of the brand itself, Charlie and Vik dig into what makes good design (and more importantly) what makes design good. They cover topics like ethics, empathy, humility, education, and bringing your authentic self to work. (Also, one correction—The Cut is based in Perth, not Melbourne. Sorry, Scott.) Links from this episode Charlie Gleason Goodfilms Unbound The Cut (which is based in Perth, not Melbourne) Heroku Brand Heroku Design Alasdair Monk’s GitHub Whimsical Figma Sketch Web Assembly / WASM Adobe Creative Suite Tailwind CSS Refactoring UI Airbnb design Glitch Offscreen Magazine Kai Brach
Episode Artwork

26. Connectivity in the Woods

Getaway is a startup that offers short-term rentals. They specialize in ensuring that the domiciles they offer are far outside city limits and often inaccessible to Internet and cellular connectivity. Zach Feldman, their VP of Technology, chats with Jason Salaz, a member of the Heroku Support Team, about the unique challenges this requirement imposes. For example, rather than providing a physical key, guests can unlock their cabin door's smart lock with a unique pin code. In order to support their efforts to scale, a custom API was built to ensure that pin codes are registered and deactivated for every check-in and check-out. Cabins are also equipped with other IoT automation devices, such as leak sensors, which report back to Getaway House if pipes are leaking. Both of these technologies were designed to work on the low latency connections that the cabins are equipped with. Relying on SMS is another way that the team is able to provide service, as those networks predate much of the current infrastructure that smartphones have come to rely on. Building correct and functional software is difficult, but Zach notes that there's an even greater challenge in scaling fault-tolerant systems in the woods. Links from this episode Getaway is the service featured in this episode POTS lines are still in service to provide telephone service in remote locations
Episode Artwork

25. Building Enterprise-Level Applications with Web Components

Heroku Front-end Engineer Jamie White sits down with René Winkelmeyer, a developer evangelist at Salesforce, to talk about the company's commitment to advancing web components. Web components are a collection of standardized web and browser APIs designed to overcome some of the limitations with the design of the Internet, particularly when it comes to page rendering. Web components exist outside of web frameworks such as React, Ember, or Vue in that they are built using standard web technologies and can be used in any application, regardless of the framework or language it's architected in. They're built for reusability and consistency across your application's UI. Lightning Web Components is a toolkit built and open sourced by Salesforce to ease the development of web components. These components are Enterprise-level, in that they provide functionality for many complicated UI scenarios. Although there are other web component frameworks, such as LitElement, a core goal of LWC is to make the process of building web components more declarative. The conversation turns towards attracted Salesforce to investing time in web components, with the conclusion being that open standards would continue to succeed in the future when compared against closed and proprietary tools. Their focus is also on ensuring that accessibility needs are met for every user of a website. Links from this episode The Lighting Web Components site has more information on LWCs, including documentation and a demo application. The LWC GitHub repo is where all of the community conversations occur. LitElement is one alternative web component framework You can follow René on Twitter @muenzpraeger
Episode Artwork

24. Side Projects for Fun and (not necessarily) Profit

The web started off weird, and there’s a wonderful and concerted effort to ensure that, at least parts of it, stay that way. Heroku designer Charlie Gleason and lead strategist Stephen Barlow dive into their experiences working on side projects—small, silly, funny, and emotive vignettes on the web—that span random Arrested Development episode selectors, Kanye West browser-based mini games, collaborative art projects, and everything in between. Learn how to get involved with your own community of makers, why it’s more important to have fun than it is to try and get internet famous, and some things to look out for when working with others. So, put away the kanban board, get inspired, and keep the internet weird with a side project of your own. Links from this episode Charlie’s music video, Tweetflight Stephen’s Kanye Zone Stephen’s community, Botnik Indie game company, Blyts Matt Desl (canvas-sketch) Jenn Schiffer Glitch Tim Holman
Episode Artwork

23. The Changing Landscape of the Tech Industry: Diversity

Chris Castle continues his conversation with Claire Lee, the head of the early stage group at Silicon Valley Bank. In this half, Claire begins by providing hard data that indicates companies which are founded by individuals from diverse backgrounds are wildly profitable. She goes on to say that conversely, the members in the top VCs firms are of a disproportionate make-up. She concludes that in order for more funds and ancillary services to be available to start-up founders, the individuals distributing the capital also needs to change, in order to give everyone a fair shot at success. Claire goes on to point out that in addition to money, mentorship is a valuable (and limited) resource in Silicon Valley. A good partnership with a VC includes them granting access to advisors, potential board members, and potential customers. Her passion extends beyond just funding good ideas; it's about making connections between people and helping them to grow. The episode concludes with advice and encouragement for anyone interested in founding a start-up. If you feel that you can solve a problem in ways that no one else has before, that passion will manifest itself into an opportunity in one way or another, whether that's within a start-up accelerator or in a digital community. Surround yourself with people who believe in you. Links from this episode Several resources for founders just getting started with their idea were mentioned on this episode: Startup Grind Tech Stars Endeavor Global For legal assistance, the following firms were offered: Cooley WilmerHale For staffing, Atrium was one option which Claire named.
Episode Artwork

22. The Changing Landscape of the Tech Industry

Chris Castle sits down with Claire Lee, the head of the early stage group at Silicon Valley Bank. Claire discusses the various startups she is involved with across various sectors, such as cleantech, fintech, and healthcare. Much of the conversation revolves around her experience at Recode's Code Conference 2019 and three lessons she took away from her attendance. First, media platform companies such as YouTube, Facebook, and Twitter need to make large changes to become more transparent. Their user base is losing trust due to the persistent problems of hostile environments, hate speech, and misinformation. The second takeaway was on the role of technology throughout our lives. For example, automated content moderation through AI can only go so far, as the technology behind them require a certain baseline standard of ethics which is as yet to be defined. A generation of new users are looking for tooling to place constraints on bad actors, which are problems that have not been tackled at scale. Finally, Claire's third realization was the adaptation of technology in decidedly non-startup environs. For example, she cites how both Harley Davidson and Goldman Sachs are revolutionizing their businesses to adapt to both new consumer needs and to attract engineering talent. Both consumers and employees are demanding better corporate values before acquiring or working for a brand. Links from this episode: Recode's Code Conference is the world’s premier technology conference. Steven Sinofsky's blog post summarizing CodeCon 2019.
Episode Artwork

21. Building APIs that Integrators Want To Use

Matte Noble is a Senior Software Engineer at Sentry, an application with the capability to stitch together different developer tools through their APIs. For example, an exception that occurs in your application can be automatically represented as an item in your project management tool's backlog. On top of this, Sentry provides a platform for tools to also integrate with. Matte identifies his past work experiences as leading him to conclude that when building an application like this, it's important to consider your two types of users as having distinct concerns: one group is content with using the product as-is, and another group is the set of developers who are building tooling and integrations for that first group. By intentionally building your product as a set of APIs that communicate with various systems, you simultaneously build features your users want that your integrators can build on top of. In order to design a good interface, Matte says that it's important to keep the responses concise, in order to avoid blurring the lines between individual resources and their responsibilities. In order to translate your internal understanding of your product's primitives into something consumable, it's important to listen to your customers and ask what their needs are, before simply exposing an API that is hard to change once it's public. Sentry's primary technical challenges are surfaced in one of two ways. First, there's an issue of consistency, in that if two services are being connected, and one of them fails for some reason, Sentry is responsible for reacting to that, even if the external service did not provide any indication that something went wrong. Second, while Sentry is sufficient at handling large volumes of data, the same might not be true of a service they are pushing data to. In order to make Sentry scalable, it's not just a matter of working with their own engineering and product teams: they must also be mindful of third-parties over which they have no control. The episode concludes with Matte's advice for any organizations interested in offering an add-on marketplace. For him, it's about providing capabilities that make the integrator want to integrate with your platform. For example, if billing is a component of the marketplace, it's important to build tools and features that allow an integrator to understand the revenue that they're making from your ecosystem. It's also important to focus on request/response times and errors rates, so that you can have the confidence in the health of those integrations and fix potential issues as soon as possible.
Episode Artwork

20. Becoming a Junior Developer

Chris Castle sits down with Shirley Xu, who went through a coding bootcamp, and Eric Chen, who is a recent graduate, to talk about their journey into their first programming jobs at Heroku. For both of them, the experience of programming in a day-to-day role is vastly different than what they experienced at school; namely, rather than analyzing algorithms, they were exposed to Ruby, Rails, and entire groups of people involved in shipping features. They recognize that they went through a period experiencing imposter syndrome, before realizing that every developer, no matter their status, shares those same feelings. Certain soft skills were also acquired. Eric learned how to move past his fear of looking ignorant and just ask questions whenever he didn't know a term or a process. He felt that this made him into a better engineer and, besides which, no one had ever refused to explain a concept. Shirley discovered that in order for her to achieve her goals, she needed to express them clearly to her mentors and manager. For example, after she expressed that she would one day like to become a technical lead or manager, her mentor was better able to develop a long term plan of the concrete steps that Shirley would need to take to get there. Tech moves fast, and a portion of this episode is dedicated to how everyone keeps up with the latest trends and terms. All agree that the breadth of knowledge is simply too much to consume, and it's okay to not know everything. That doesn't make you a better or worse developer: it simply means your expertise lies elsewhere. The episode concludes with some advice for anyone not in software development, but is considering a change. Eric suggests keeping yourself motivated, with time blocks in your schedule dedicated to simply learning. Shirley provides a long list of resources, as well as a six-to-twelve month timeframe to go from a neophyte to your first job. Links from this episode Several coding bootcamps and online tutorials were mentioned as possible starting points for those interested in transitioning into a career in tech: HackBright CodeAcademy PluralSight L'Ecole No 41 freeCodeCamp
Episode Artwork

19. Securing the Web with Let's Encrypt

Josh Aas, the co-founder of the non-profit Internet Security Research Group (ISRG), is interviewed by Craig Ingram, a Runtime Engineer at Heroku. Amongst other outreach programs, ISRG is in charge of developing Let's Encrypt, which is a Certificate Authority (CA) designed to provide free TLS/SSL certificates to any website on the web. While starting ISRG in 2013, Josh noted that only about a third of websites on the Internet were secured by HTTPS. He discovered that not only was the price of acquiring a certificate a barrier to entry, but the technical requirements to apply a certificate was also cumbersome. Let's Encrypt began as a way to simplify the application of aTLS/SSL certificate for any website. Founding a CA was no easy task. To begin with, a brand new CA is "untrusted," and it takes up to a decade for every company and Internet-ready device in the world to accept your validity. In 2015, Let's Encrypt partnered with another CA called IdenTrust by having them cross-sign certificates. This allows Let’s Encrypt to operate and provide certs while making progress towards becoming a fully independent CA. Over the years, there have been several trade-offs between Let's Encrypt original goals and features that users have requested. Although ISRG would like to limit the technical scope of what Let's Encrypt offers to keep the process simple, they have worked through feedback to ensure that they meet a majority of their users' needs. Although HTTPS certainly helps secure communication between a user and a website, there are still more layers of the Internet which require protection. One of these is called Border Gateway Protocol (BGP) hijacking. The team is working on mitigations to make these sorts of attacks impractical. Links from this episode Let's Encrypt is a free, automated, and open Certificate Authority with the goal of creating a 100% encrypted Web. The Border Gateway Protocol is, in Josh's opinion, another major component of the Internet which requires stronger security.
Episode Artwork

18. The Making of Trailhead

Tyler Montgomery, Trailhead's engineering director, and Shaun Russell, its principal engineer, kick off a conversation with Chris Castle as to how Trailhead came about. One of Salesforce's developer evangelists, Josh Burke, wanted to create some teaching material for classes he taught. The idea was that students wouldn't just read some content and take a quiz; they would perform real actions, such as making a dummy user an admin, and an API call would assert that they accomplished the task successfully. Due to its tight deadline of just six weeks before Dreamforce, the Trailhead team built the app using Ruby and Rails, and hosted the site on Heroku. Although they've seen huge growth, a lot of naive technical decisions have lead to a mix of addressing performance issues as well as launching new features over the past few years. Their largest near-outage came about when hundreds of thousands of students in India began to use the site all at the same time in order to participate in a competition. Heroku was able to scale up, but this exposed many problems which, when the traffic subsided, better prepared the Trailhead team for future scaling issues after all the code fixes were in place. The conversation concludes with advice on scaling up an application on Heroku. Shaun suggests an APM tool like New Relic to stay on top of performance problems before they become an issue. Tyler suggests implementing an entire pipeline of tooling--PagerDuty, errors logged into Slack, segmented environments for staging and production--before continuing work on any feature code. Links from this episode Trailhead is an e-learning platform focused on Salesforce and other web technologies New Relic is a monitoring tool for an application's performance
Episode Artwork

17. Integrating Terraform with Heroku

Terraform is an open source project to help automate the provisioning of infrastructure resources and services for your application. It integrates with cloud platforms through open source plugins, called providers. Mars Hall is a Heroku engineer that works on the Heroku provider. Rather than using a CLI or a web UI, Terraform provides a platform-agnostic configuration file written in the Hashicorp Configuration Language, or HCL. This sets Terraform apart from similar tools like Chef, which relies on Ruby, or Ansible, which only relies on provisioning server state. The conversation veers towards the architecture of a provider and how individuals can contribute to the Heroku provider integration. Essentially, a platform exposes some HTTP endpoints that a provider than communicates with. This means that while open source community can contribute to a provider, there are some feature requests which are dependent on the platform exposing accessibility first. Mars suggests that individuals first open an issue with their request, and a Heroku engineer will convey whether that's on the roadmap or free to accept pull requests. Although HCL is easy to learn, all of the providers—and Terraform itself—is written in Go. Some best practices are provided for larger organizations interested in working with Terraform on Heroku. Among these include strict guidelines for always using Terraform to manage an app's configuration; using consistent naming schemes to indicate that an app is managed by Terraform; and relying on provisioner health checks to help guide Terraform's automation steps. The episode ends with a look forward at the next release of both Terraform and Heroku's provider plugin. Links from this episode Terraform, an open source program to create and change infrastructure, is the core subject for this episode On GitHub, the Terraform Providers organization lists all of the open source providers that work with Terraform Using Terraform with Heroku is a Dev Center article with more information on the integration of Heroku with Terraform
Episode Artwork

16. Accessibility in Web Standards

Léonie Watson does many things: she worked on overhauling the UK government's digital services, is on the W3C advisory board, acts as co-chair of the W3C web platform working group, is an advisor for Google's Accelerated Mobile Pages project, and also runs the Inclusive Design 24 conference. She also happens to be visually impaired. The show begins with how she went from drama school towards a career as a web programmer, and how she become a strong advocate for improving accessibility in web standards. Léonie stresses that anyone can get involved in the decisions that power the web by contributing to the W3C's public conversations at GitHub. She details the lifecycle of a proposal, and highlights how considerations such as accessibility, security, and privacy are built-in. While existing standards are well-conceived for realms such as SVG, HTML, or ARIA, there are still new frontiers to work towards every year, particularly with API-driven interfaces. Léonie mentions how the interfaces for the "Internet of things" still need to make progress to ensure those devices are usable by all. There are several tools to help software developers build more accessible systems. Chrome's Dev Tools, for example, have a suite of checks you can run on a website to grade its accessibility. Platforms such as Axe or Tenon can run automated tests as part of a CI flow to maintain high quality code before it ships. For Léonie, it's important for designers, developers, and product managers not to be overwhelmed by all the requirements and allow perfect to be the enemy of good. Even attempting inclusive design advances technology towards a much better place. The conversation continues with some discussion on Léonie's work with TetraLogical, a consultancy focused on accessibility in emerging technologies, such as virtual reality, augmented reality, and WebXR. By setting a standard for inclusive design principles, Léonie hopes that organizations can incorporate accessibility as yet another aspect of good design, beyond just the bare minimums required by tech specs and test suites. Links from this episode Nomensa and The Paciello Group are two agencies Léonie Watson worked at. Their focus is on better UX for web accessibility. She's since founded TetraLogical, which focuses on accessibility issues in emerging technologies like VR, AR, and WebXR. is the central meeting point for many of the discussions on web standards is Léonie's blog, focused on accessibility in web standards Inclusive Design Principles is a set of guidelines on how to go above and beyond in making your site accessible Axe is an accessibility engine for automated web UI testing. Tenon is an "accessibility as a service" platform for websites.
Episode Artwork

15. Pursuing a Career in Tech

Designer and front end developer Charlie Gleason and developer David Routen are both on Heroku's marketing team, and both of them transitioned into the world of programming from disparate career paths. For them, moving into tech was about following their passion for creative problem solving. They did so by first creating a plan for what they needed to learn. After viewing several job postings, they got a sense of what skills each potential employer required, and then set about to learn them. Fundamentally, they believe that a strong grasp of the building blocks of the web, like HTML and CSS, plus at least one other higher level language (JavaScript, PHP, Ruby, Python), is a great way to get started. There are many free resources to learn programming on the web, but there are also more structured courses which you can pay for. In order to practice those skills, they recommend speaking to members of your community who need basic web work done, and asking if you can volunteer there in exchange for putting the work in your portfolio or CV. This will show potential employers an idea of who you are and what you're capable of. Even if programming isn't your thing, there are loads of other roles as well, such as data scientists, project management, or software quality assurance. As well, following people in the industry—either through their blog, Twitter, or local meetups—is a great way to network and hear about additional opportunities. Links from this episode Adobe Creative Suite Figma Sketch Facebook Open Source Codecademy Udacity edX Udemy Google Web Fundamentals Pluralsight A link to ‘Learn how to program’ in a search engine
Episode Artwork

14. Talking About Talks

This episode begins with a roundtable introduction from five Herokai engineers who describe what motiviated them to speak at their first conference. If you're a first-time speaker, it's best to let conference organizers be aware of this, not only because they will support you, but also because they will try to give you a prime time slot in order to boost your message (and spirits). The group then delves into how to prepare and practice for your talk. In general, they agree that improvising is not a good idea, unless you're absolutely an expert in the subject matter. You should also be able to account for the lack of Internet access, which means that live coding is also not recommended. Every speaker is nervous, no matter how many talks they give, but everyone in the room wants you to succeed, and doesn't know if you've skipped a specific sentence or word. It's best to just roll with the flow. In terms of deciding the subject matter, some of the engineers pick two or three variations on a single topic, and try to submit each flavor to as many conferences as they can. Another strategy is to hone one really unique angle--or even choose a subject matter that is so "common" to a developer's day-to-day routine they don't think about it. Those sorts of talks get people to really engage in something they may have never realized before. The conversation concludes with ways to get better at public speaking, whether that's rewatching your recorded self and noticing your body language, or simply giving the same talk at another conference, and building on what works. Links from this episode Fog City Ruby, a San Francisco-based meetup about Ruby, co-organized by Stella Cotton caffeinate, a MacOS app which prevents your laptop from entering Sleep Mode
Episode Artwork

13. oclif: An Open Source CLI Framework

For many years, Jeff Dickey was a lead architect for Heroku's CLI tool, which was used by application developers to get their apps deployed to Heroku's platform. He muses on his history with CLIs with Nahid Samsami, a director of product at Heroku, as the two of them worked together on oclif. oclif was designed from the start to be a framework for developers to use when building their own command-line interfaces. It's currently written in TypeScript, but Jeff goes through its four-year history, starting with its roots in Ruby and on thorough its Frankenstein's monster mashup of Go and JavaScript. While each language had its pros and cons, the key constraint was how the resulting command-line binary program would be distributed. The project has been incredibly popular, both through internal adoption at Heroku and Salesforce, to its reception and use from other companies, as well as the active contributions made on GitHub. The episode concludes with some theories about the future of CLI tooling. PowerShell, for example, is a fully object-oriented environment which a developer can program against. Jeff is also interested in better integration between the terminal and UI elements. Links from this episode, the main landing page for learning more about oclif Microsoft's Powershell, which Jeff believes is the most incredibly advanced CLI platform
Episode Artwork

12. Mindfulness at Work

Francis Lacoste, a Director of Engineering at Heroku, is a longtime meditation practitioner. In 2015, he attended public seminar on mindfulness by the Search Inside Yourself Leadership Institute, which was co-founded by a former Google engineer. The workshop emphasized mindfulness as a benefit to businesses by framing the mental health benefits as something that could improve worker productivity. Enlightened by this discovery, he worked to bring the lessons over to Heroku. Heroku's remote culture introduced some challenges to the original structure of the program. Participants are connected through Zoom meetings, rather than being seated in a room together. As well, the workshop take place over the course of a week, rather than two very long days. Herokai have responded very positively to the lessons, and some have earnestly applied the practices at home and with their families. The actual practice itself is very secularized, even though it draws on Buddhist traditions. Francis Lacoste believes that culturally, we are not given the appropriate tooling to deal with conflicts and stress, and finds mindfulness to be a fantastic aid to those problems. Links from this episode Search Inside Yourself DIY Meditation Guide Social Meditation
Episode Artwork

11. The Agony and Ecstasy of Maintaining Good Documentation

With the explosive growth of people using, and contributing to, open source projects over the last decade, more and more of us are spending their time reading, writing, and understanding documentation. Heroku's Dev Center is the central hub of documentation for Heroku, covering everything from getting started, to how Heroku works, to extending the platform. It acts as a manual for the entire platform, spanning an enormous number of topics and tools. Stephen Barlow, lead strategist for Dev Center, joins Heroku designer / developer Charlie Gleason to discuss why good documentation is so important—from some of the common challenges you and your team might face while writing them, to advice for rationalising and improving your documentation workflow. Tune in to learn why good docs aren't just good—they're great. Links from this episode Heroku Dev Center Heroku Buildpacks Rust Create React App Write The Docs Conference Prettier Typescript Git hooks and Husky Runbooks Heroku Changelog Stack Overflow
Episode Artwork

10. How to Learn Something New

Vaidehi Joshi found that many resources on the web about core computer science concepts she wanted to know more about were either too obtuse or too academic. She started a blog, basecs, where she wrote down something she had learned that week--every week--for an entire year. While learning something new in and of itself was a delight, her curiosity led her to question how people learn best. She discusses the Feynman Technique, which, through a processes of iteratively explaining a concept to someone who doesn't know anything about it, strengthens the knowledge for both the student and the teacher. The best way to do this is by telling a narrative. It keeps the listener engaged, while also serving as a way of identifying gaps in ones' own understanding, as new questions arise. Links from this episode basecs and baseds are two of Vaidehi's websites which teach concepts about computer science and distributed systems The Feynman Technique: The Best Way to Learn Anything
Episode Artwork

9. Coordinating Remote Work

Heroku splits its units of work into squads; on this episode, we're joined by some members of the squad responsible for the Private Spaces feature. Every member of the squad is remote from one another. The team talks about the pain points around this setup, and the solutions they've set up to minimize feelings of isolation. One tactic has been to keep a long-running meeting URL. Individuals from around the team can hop in and enter a space where they can just be social with one another. Each teammate also explains why they joined Heroku, and what they appreciate about a company that values remote work. They conclude with a discussion on their favorite programming languages and editors. Links from this episode An introduction to Heroku's Private Spaces
Episode Artwork

8. Sharing Data with Dataclips

Chris Castle introduces Becky Jaimes, the product manager for Heroku Dataclips. Dataclips is a feature that allows you to save and version SQL queries against a Postgres database. You can export these queries to JSON or CSV, share them online, or simply access them through an HTTP API. The two discuss the history of Dataclips, namely what its original needs were and how it has evolved. It was originally targeted towards individuals who simply wanted a quick way to get access to rows from a database, and now it's grown to be a useful source of information for BizOps teams, engineers, and product managers. The newest release of Dataclips came out of a very long beta program involving customers of various sizes. Some customers had a few dozen queries they accessed frequently, while others had thousands of them. The team at Heroku wanted to create a one-size-fits-all solution, while at the same time reducing technical debt which had been a hinderance to shipping quickly. Becky shares some of the features that are now available. Links from this episode A Dialog with Your Data Using the New Dataclips Dataclips is often used as a lightweight Extract, transform, load (ETL) framework
Episode Artwork

7. Application Performance and Building SaaS on PaaS

Chris Castle introduces Ryan Townsend, CTO of Shift Commerce, and the two begin by discussing the absolutely abysmal performance of web sites in areas with bad latency: airplanes, the rural countryside, or even just within a crowded cafe or conference. Shift Commerce provides a customizable shopping platform for its customers, who are several big brand retailers. For them, every millisecond of delay means lost revenue, as studies have shown that customers are unlikely to complete their purchase if it takes too long. It's important for Shift Commerce to stay hyper-tuned into its performance. Since it's a multi-tenant application, they have several safeguards in place to ensure that one customer's traffic spike doesn't affect any other retailers. One such strategy is to lean into several of Heroku's features, such as its API, to do some of the heavier lifting. They're perfectly contently to let Heroku manage the operations work while they focus on the application itself. When it comes to increased traffic, although there are "quick wins" by increasing the number of dynos available, fundamentally what Ryan has found important is to think about the architecture of the site holistically. That means everything from trimming down the amount of JavaScript delivered to efficiently managing the number of database connections made. Links from this episode Ryan's talk at #PerfMatters Conference 2019 Web Performance Optimization stats, listing articles about how popular websites have sped themselves up How One Second Could Cost Amazon $1.6 Billion In Sales Facebook's '2G' Tuesdays, an initiative that artificially slows down the Internet connection at Facebook to spur empathy towards creating faster response times
Episode Artwork

6. Making Remote Work Work

More than half of the employees who work on Heroku are remote or distributed employees, meaning Heroku is what you might call remote-first. Host, Chris Castle, brings together five Heroku employees who have had interesting distributed employee experiences. They share some personal stories and discuss setting boundaries, self-awareness, timezones, and some advice for others interested in distributed work. Raúl Barroso is based in Madrid, Spain. He compares his experience working at Heroku HQ with his current experience as a distributed employee, working from Spain with a team across Europe and the U.S. He also shares his thoughts on the phrase “remote employee” vs “distributed employee” (hint: use “distributed” if you are serious about fostering a culture that values distributed employees as equals to those at HQ). Alasdair Monk is based in the UK. He published a blog post in September 2016 titled Making remote work: What we’ve learned at Heroku discussing distributed work in three categories: working asynchronously, working together, and staying aligned. He reflects on his experience in the past two years since writing that post and also shares his perspective of UX and Design work as a distributed employee. Jon McCartie lives way up in northern Idaho by the Canadian border. He and his wife decided to spend 1.5 years with three kids (ages 7, 5, and 2) traveling around the western U.S. in an RV. Oh, and he did this while working on the Customer Support team -- successfully. He shares some fun stories of video meetings with gorgeous views, choosing the right size RV, and using a mobile Wi-Fi hotspot as your family’s primary internet connection. Here is a picture of Jon’s “office”. Annie Sexton currently lives in Austin, TX. For most of 2017, she was a “digital nomad” fulfilling a life-long dream of hers. She started with a month in Thailand, and then went to Japan, Bali, Morocco, Croatia, Slovenia, back to the U.S., and then back to Thailand, and then Panama. Her Instagram makes it look glamorous, but she says, “it’s easy to romanticize the lifestyle of working on your laptop on the beach drinking coconut water, but it’s just not like that.” Niklas Richardson is based in the UK. He shares why and how he put his desk in the garden. He poured a foundation and then bought a pre-fab shed that he had insulated and electrified. Here’s what Niklas’s beautiful backyard office--aka garden oasis--looks like, and also the website he mentions in the podcast showcasing other beautiful sheds. Links from this episode Alasdair Monk’s blog post Making remote work: What we’ve learned at Heroku Website with other beautiful sheds Niklas mentioned
Episode Artwork

5. Solving Social Problems with Data Science

Isaac Slavitt is the co-founder of DrivenData, a platform for organizations to solicit help from data scientists to solve real-world problems. DrivenData does this by running "competitions" which asks teams to comb through data sets to solve problems for cash rewards. One such competition was Zamba. Researchers set up cameras in African forests and asked engineering experts to develop AI software which could classify the types of animals which were captured. This would then help with research and conversation efforts without disturbing the natural ecosystem. Another such competition is DengAI, which seeks ML techniques to try and predict future outbreaks of dengue fever. Isaac concludes the interview by talking about DrivenData's tech stack. He discusses the uses of both R and Python in the data scientist community. He notes that many computationally intensive task, such as ML classification and testing, are able to be offloaded to a service like Paperspace, while the majority of their platform runs on Heroku. Links from this episode DrivenData Zamba DengAI Paperspace
Episode Artwork

4. Delivering Amazing Presentations

Nickolas Means likes to tell stories. His conference talks [1] often center around a curious anecdote, but he deftly weaves both technical and organizational relevancy into them. Nickolas talks about how he builds a talk from conception to execution and goes over some fundamentals of good presentation slides. The goal is to provide a narrative without overwhelming the user with too much textual content. He continues with advice for novices and experts alike, including how to craft a CFP that will increase the likelihood of your talk being accepted. He suggests that new speakers choose a larger conference to speak at, rather than a smaller one, as they have more capacity to provide mentoring. Even if you're not a Ruby or Rails developer, their conferences tend to be very welcoming, and he suggests taking a look at to find one that fits. Links from this episode Nickolas’ conference talks Nickolas Means on Confreaks TV How to Talk to Developers by Ben Orenstein What Your Conference Proposal Is Missing by Sarah Mei Better talk proposals in 3 easy steps
Episode Artwork

3. Spreading the Database Love

Brendon Murphy, CTO of Kajabi, talks about his company's experience with Dataclips [1]. Instead of requiring developers to connect to their database, everyone in the company is able to generate analytics on-the-fly, and they even democratize the information via a Slackbot. Their marketing team is able to get real-time feedback on their campaigns through [2] The advantage of using Dataclips dovetails with their preference for using Heroku in general. While they could build their own wrapper to communicate with Postgres, or even manage their own infrastructure, they've found that the financial and operational costs are simply not worth it. By offloading this vital work, they free themselves up to focus on building features for their users. Brendon concludes by talking about Postgres, and why it's the right choice for his team. It can act as a NoSQL document store via its JSONB data type, serve as a key-value store obviating the need for Redis, and comes with strict type assurances reducing the need for checks in the software layer. He also mentions add-ons provided by Heroku, such as PGBouncer [3], along with his feature request for how Heroku can better serve Kajabi's large data needs. Links from this episode Sharing Query Results with Dataclips chat bot Heroku buildpack: pgbouncer
Episode Artwork

1. Running Grails in Production

Andrew Garcia is the co-founder of Goodshuffle, and as one of the first Grails users on Heroku, he worked closely with Joe Kutner, Heroku's Java Platform Owner over the years. They chat with Chris Castle, a developer advocate at Heroku, about Goodshuffle's experience with building a startup on top of the JVM. When building an application, it's often tempting to reach for the latest and greatest technologies to build your app. Andrew Garcia argues for something different: by using "boring" technology--that is, languages and frameworks that have been around for years, not months--you can iterate much more quickly on features. He's chosen JDK8 (released in 2014) to run Goodshuffle, a startup founded in 2013 to help event companies manage their business operations. Goodshuffle uses frameworks like Gradle and Angular because of their stance on convention over configuration, which is another opportunity for being more productive. The more reliable the tools you use are, the more you can focus on your users needs. Links from this episode
Episode Artwork

2. Ruby, Regexes and Risk: Aaron Patterson Explains Why Hiring Open Source Developers Will Make Your Company Stronger

In this episode Aaron Patterson joins our own developer advocate Jonan Scheffler to discuss his experiences as an open source developer within GitHub, and explains how he manages to balance his work as a member of the Ruby and Rails core teams with his other responsibilities. Aaron is the only member of both the Ruby and Rails core teams, and he's been working with Rails since 2005 when his friends attended the No Fluff Just Stuff (NFJS) Pacific Northwest Software Symposium and heard Dave Thomas speak.(1) In discussing his path to becoming a Ruby developer, Aaron walks through his time working with Perl and Java, covering language regular expression engines (PCRE, Oniguruma, POSIX), the joy he felt in finding Ruby, and how falling in love with Ruby eventually forced him to become a C programmer. Later in the episode Aaron offers some advice to aspiring open source developers and discusses the future of Ruby, along with some features he would like to see around deep freezing data structures(2) and concurrency/parallelism(3). If you’d like to learn more about Ruby development and how you can contribute, please visit Links from this episode Dave Thomas "Ruby on Rails" talk abstract from NFJS PNW Software Symposium Vaidehi Joshi explains frozen hashes in Ruby Rob Pike explains concurrency and parallelism at Waza 2012: