Podcast appearances and mentions of Joel Spolsky

ux sten hash detecting lifeboats stack overflow cultural anthropology ux research joel spolsky

Play Episode Listen Later Jun 10, 2022 28:54

HASH, where Maggie works along with Stack Overflow cofounder Joel Spolsky, is an open-core platform for creating simulations that help people make better decisions.Explore Maggie's writing on everything from digital anthropology to best practices for illustrating invisible programming concepts.Maggie recommends the Nielsen Norman Group website as the best resource for folks getting up to speed on research-based UX.Today's Lifeboat badge goes to user Sten for their answer to Detecting transparency in an image.

Ep. 225 - The Tsunami Arrives and Architecture Astronauts

The Local Maximum

Play Episode Listen Later May 10, 2022 40:50

Max talks about the financial tsunami predicted last year starting to come to fruition, and then dives into a 2001 article by Joel Spolsky and takes a more positive view of architecture astronauts.

architecture astronauts tsunamis arrives joel spolsky

221. Spolsky’s Maxim & Starting from Scratch

THUNK - Audio Interface

Play Episode Listen Later Mar 13, 2022 10:47

Sometimes, it feels like the best way forward on a project is to throw everything out & start over from scratch, but Joel Spolsky is adamant that this is a terrible idea, & there's decent evidence that he's right.

starting from scratch joel spolsky spolsky

Post Status Excerpt — The Block Protocol, Tumblr, and Complexity: Lesley Sim

WordPress | Post Status Draft Podcast

Play Episode Listen Later Feb 10, 2022 28:14

In this episode of Post Status Excerpt, David talks with Lesley Sim about Joel Spolsky on the Block Protocol, Matt Mullenweg for taking over for the exiting CEO of Tumblr, and a blog post by Dan Devine entitled "The Complicated Futility of WordPress."Why This Is Important: It's good to examine the views of influencers inside and outside the WordPress community about managing content (especially with blocks) and how complex content management systems (like WordPress) have become. Tumblr is a potential wildcard — social network, gateway to more advanced publishing, both, or neither?Every week Post Status Excerpt will brief you on important WordPress news — in about 15 minutes or less! Learn what's new in WordPress in a flash. ⚡You can listen to past episodes of The Excerpt, browse all our podcasts, and don't forget to subscribe on Spotify, Amazon Music, Google Podcasts, iTunes, Castro, YouTube, Stitcher, Player.fm, Pocket Casts, Simplecast, or by RSS.

ceo spotify player seo stitcher google podcasts castro wordpress complexity protocol tumblr amazon music excerpt pocket casts simplecast matt mullenweg dan devine joel spolsky post status lesley sim

OMG 6.0 already?!

The WP Minute

Play Episode Listen Later Feb 2, 2022 5:30

News Matt Mullenweg recently announced that he would be personally running Tumblr for a while. Tumblr lost their CEO and Matt is making this his top priority within Automattic for the immediate future. Keep an eye open for improvements in the community. Are you or your clients using Wordpress.com? Wordpress.com is now making it possible to purchase certain plugins directly on the plugin page. The plugins that are available right now are for WooCommerce subscribers with a Business or eCommerce plan. Keep an eye out for more paid plugins appearing in 2022. Josepha Haden Chomphosy on make.wordpress.org shared the potential release timing for 2022 of WordPress. This release looks like this right now: 6.0 – Late May 6.1 – Mid October If you have project management skills or can lend a hand on these next major releases, contact the release team. The Preliminary Roadmap for Gutenberg 6.0 has also been published by Matias Ventura on make.wordpress.org. There are four phases outlining the long-term roadmap. Events The schedule of WordCamps is published over on WordCamp central. Many are in the early stages of planning and don't have a date yet. WordCamp US has been scheduled September 9-11, 2022 in San Diego, CA. From Our Contributors and Producers To celebrate Black History Month Underrepresented in Tech will tweet about a black tech innovator/inventor every day in February. Google is burying FLoC (Federated Learning of Cohorts) in its sea of abandoned experiments. Sarah Gooding over at the WPTavern writes that Google's FLoC ran in limited markets and received overwhelmingly negative feedback from the tech industry that left Google with an uphill battle to get enough buy-in to proceed. So now Google is proposing topics. Stay tuned for the feedback on this new proposal. Squarespace rolled out an expansion of their Member Areas program. This allows publishers to earn money selling instructional and other kinds of content online through private members-only sections of their Squarespace website. Would you like to see block standardization across the web? Joel Spolsky has an interesting blog post asking what if blocks were interchangeable and reusable across the web? He suggests a non-proprietary, block protocol that will be open and free. His article is an interesting one to read. The WPMinute Contributor spotlight is on Aurooba Ahmed this week. She has created a new plugin called the superlist block for WordPress. This is Aurooba's first publicly released plugin on WordPress.org. The plugin lets you add other blocks within the list items essentially making it supercharged. Listen to Joe Casabona's Creator Toolkit on Creator Clock Minute Transcript: Hey everybody, Joe Casabona here and you are on the Creator Clock. Over the last few weeks, I've spent a bunch of time putting together what I call creator toolkits. This is based on a podcast I had several years ago, but it's all about tools that you can use to build specific WordPress sites. For example, I have a toolkit for creating online courses or creating a podcast website. So how did I come up with these recommendations? Well, I've been using WordPress for a very long time. I've tried a bunch of tools and I've picked my favorite. So I want to highlight one of these toolkits and it is the creating online courses toolkit. I would recommend Nexcess' managed WordPress hosting for this because you're going to be accepting payments. The Kadence theme with Kadence Pro is a fantastic theme for this. For the LMS plugin, I recommend LearnDash. LearnDash and Kadence work very well together. For list-building, I recommend ConvertKit, and to tie it all together to everything you use outside of WordPress, I would recommend, Uncanny Automator as the automation plugin. If you want to see more creator toolkits, you can head over to creatorcourses.com/toolkits. Or you can continue the conversation with me over on Twitter @jcasabona. New Members: Thanks to our new member Svilena Peneva from NitroPack. Thanks to all of the members who shared these links today: Birgit Pauli-HaackMichelle FrechetteDaniel SchutzsmithDavinder Singh KainthJoe CasabonaJeff Chandler Thanks to you, dear listener, for tuning in to your favorite 5-minutes of WordPress news every Wednesday. ★ Support this podcast ★

ceo google business tech san diego ecommerce wordpress tumblr squarespace cohorts gutenberg lms convertkit woocommerce automattic floc wordcamp wordcamps joe casabona joel spolsky learndash wordcamp us google's floc sarah gooding josepha haden chomphosy

Breaching the Coding Gates with Anil Dash

Screaming in the Cloud

Play Episode Listen Later Dec 29, 2021 39:03

About AnilAnil Dash is the CEO of Glitch, the friendly developer community where coders collaborate to create and share millions of web apps. He is a recognized advocate for more ethical tech through his work as an entrepreneur and writer. He serves as a board member for organizations like the Electronic Frontier Foundation, the leading nonprofit defending digital privacy and expression, Data & Society Research Institute, which researches the cutting edge of tech's impact on society, and The Markup, the nonprofit investigative newsroom that pushes for tech accountability. Dash was an advisor to the Obama White House's Office of Digital Strategy, served for a decade on the board of Stack Overflow, the world's largest community for coders, and today advises key startups and non-profits including the Lower East Side Girls Club, Medium, The Human Utility, DonorsChoose and Project Include.As a writer and artist, Dash has been a contributing editor and monthly columnist for Wired, written for publications like The Atlantic and Businessweek, co-created one of the first implementations of the blockchain technology now known as NFTs, had his works exhibited in the New Museum of Contemporary Art, and collaborated with Hamilton creator Lin-Manuel Miranda on one of the most popular Spotify playlists of 2018. Dash has also been a keynote speaker and guest in a broad range of media ranging from the Obama Foundation Summit to SXSW to Desus and Mero's late-night show.Links: Glitch: https://glitch.com Web.dev: https://web.dev Glitch Twitter: https://twitter.com/glitch Anil Dash Twitter: https://twitter.com/anildash TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key, or a shared admin account, isn't going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And not, that is not me telling you to go away, it is: goteleport.com.Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key, or a shared admin account, isn't going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And not, that is not me telling you to go away, it is: goteleport.com.Corey: This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database that is not the bind DNS server. If you're tired of managing open source Redis on your own, or you're using one of the vanilla cloud caching services, these folks have you covered with the go to manage Redis service for global caching and primary database capabilities; Redis Enterprise. To learn more and deploy not only a cache but a single operational data platform for one Redis experience, visit redis.com/hero. Thats r-e-d-i-s.com/hero. And my thanks to my friends at Redis for sponsoring my ridiculous non-sense. Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's guest is a little bit off the beaten path from the cloud infrastructure types I generally drag, kicking and screaming, onto the show. If we take a look at the ecosystem and where it's going, it's clear that in the future, not everyone who wants to build a business, or a tool, or even an application is going to necessarily spring fully-formed into the world from the forehead of some God, knowing how to code. And oh, “I'm going to go to a boot camp for four months to learn how to do it first,” is increasingly untenable. I don't know if you would call it low-code or not. But that's how it feels. My guest today is Anil Dash, CEO of Glitch. Anil, thank you for joining me.Anil: Thanks so much for having me.Corey: So, let's get the important stuff out of the way first, since I have a long-standing history of mispronouncing the company Twitch as ‘Twetch,' I should probably do the same thing here. So, what is Gletch? And what does it do?Anil: Glitch is, at its simplest, a tool that lets you build a full-stack app in your web browser in about 30 seconds. And, you know, for your community, your audience, it's also this ability to create and deploy code instantly on a full-stack server with no concern for deploy, or DevOps, or provisioning a container, or any of those sort of concerns. And what it is for the users is, honestly, a community. They're like, “I looked at this app that was on Glitch; I thought it was cool; I could do what we call [remixing 00:02:03].” Which is to kind of fork that app, a running app, make a couple edits, and all of a sudden live at a real URL on the web, my app is running with exactly what I built. And that's something that has been—I think, just captured a lot of people's imagination to now where they've built over 12 or 15 million apps on the platform.Corey: You describe it somewhat differently than I would, and given that I tend to assume that people who create and run successful businesses don't generally tend to do it without thought, I'm not quite, I guess, insufferable enough to figure out, “Oh, well, I thought about this for ten seconds, therefore I've solved a business problem that you have been needling at for years.” But when I look at Glitch, I would describe it as something different than the way that you describe it. I would call it a web-based IDE for low-code applications and whatnot, and you never talk about it that way. Everything I can see there describes it talks about friendly creators, and community tied to it. Why is that?Anil: You're not wrong from the conventional technologist's point of view. I—sufficient vintage; I was coding in Visual Basic back in the '90s and if you squint, you can see that influence on Glitch today. And so I don't reject that description, but part of it is about the audience we're speaking to, which is sort of a next generation of creators. And I think importantly, that's not just age, right, but that could be demographic, that can be just sort of culturally, wherever you're at. And what we look at is who's making the most interesting stuff on the internet and in the industry, and they tend to be grounded in broader culture, whether they're on, you know, Instagram, or TikTok, or, you know, whatever kind of influencer, you want to point at—YouTube.And those folks, they think of themselves as creators first and they think of themselves as participating in the community first and then the tool sort of follow. And I think one of the things that's really striking is, if you look at—we'll take YouTube as an example because everyone's pretty familiar with it—they have a YouTube Creator Studio. And it is a very rich and deep tool. It does more than, you know, you would have had iMovie, or Final Cut Pro doing, you know, 10 or 15 years ago, incredibly advanced stuff. And those [unintelligible 00:04:07] use it every day, but nobody goes to YouTube and says, “This is a cloud-based nonlinear editor for video production, and we target cinematographers.” And if they did, they would actually narrow their audience and they would limit what their impact is on the world.And so similarly, I think we look at that for Glitch where the social object, the central thing that people organize around a Glitch is an app, not code. And that's this really kind of deep and profound idea, which is that everybody can understand an app. Everybody has an idea for an app. You know, even the person who's, “Ah, I'm not technical,” or, “I'm not really into technology,” they're like, “But you know what? If I could make an app, I would make this.”And so we think a lot about that creative impulse. And the funny thing is, that is a common thread between somebody that literally just got on the internet for the first time and somebody who has been doing cloud deploys for as long as there's been a cloud to deploy to, or somebody has been coding for decades. No matter who you are, you have that place that is starting from what's the experience I want to build, the app I want to build? And so I think that's where there's that framing. But it's also been really useful, in that if you're trying to make a better IDE in the cloud and a better text editor, and there are multiple trillion-dollar companies that [laugh] are creating products in that category, I don't think you're going to win. On the other hand, if you say, “This is more fun, and cooler, and has a better design, and feels better,” I think we could absolutely win in a walk away compared to trillion-dollar companies trying to be cool.Corey: I think that this is an area that has a few players in it could definitely stand to benefit by having more there. My big fear is not that AWS is going to launch stuff in your space and drive you out of business; I think that is a somewhat naive approach. I'm more concerned that they're going to try to launch something in your space, give it a dumb name, fail that market and appropriately, not understand who it's for and set the entire idea back five years. That is, in some cases, it seems like their modus operandi for an awful lot of new markets.Anil: Yeah, I mean, that's not an uncommon problem in any category that's sort of community driven. So, you know, back in the day, I worked on building blogging tools at the beginning of this, sort of, social media era, and we worried about that a lot. We had built some of the first early tools, Movable Type, and TypePad, and these were what were used to launch, like, Gawker and Huffington Post and all the, sort of, big early sites. And we had been doing it a couple years—and then at that time, major player—AOL came in, and they launched their own AOL blog service, and we were, you know, quaking in our boots. I remember just being kind of like, pit in your stomach, “Oh, my gosh. This is going to devastate the category.”And as it turns out, people were smart, and they have taste, and they can tell. And the domain that we're in is not one that is about raw computing power or raw resources that you can bring to bear so much as it is about can you get people to connect together, collaborate together, and feel like they're in a place where they want to make something and they want to share it with other people? And I mean, we've never done a single bit of advertising for Glitch. There's never been any paid acquisition. There's never done any of those things. And we go up against, broadly in the space, people that have billboards and they buy out all the ads of the airport and, you know, all the other kind of things we see—Corey: And they do the typical enterprise thing where they spend untold millions in acquiring the real estate to advertise on, and then about 50 cents on the message, from the looks of it. It's, wow, you go to all this trouble and expense to get something in front of me, and after all of that to get my attention, you don't have anything interesting to say?Anil: Right.Corey: [crosstalk 00:07:40] inverse of that.Anil: [crosstalk 00:07:41] it doesn't work.Corey: Yeah. Oh, yeah. It's brand awareness. I love that game. Ugh.Anil: I was a CIO, and not once in my life did I ever make a purchasing decision based on who was sponsoring a golf tournament. It never happened, right? Like, I never made a call on a database platform because of a poster that was up at, you know, San Jose Airport. And so I think that's this thing that developers in particular, have really good BS filters, and you can sort of see through.Corey: What I have heard about the airport advertising space—and I but a humble cloud economist; I don't know if this is necessarily accurate or not—but if you have a company like Accenture, for example, that advertises on airport billboards, they don't even bother to list their website. If you go to their website, it turns out that there's no shopping cart function. I cannot add ‘one consulting' to my cart and make a purchase.Anil: “Ten pounds of consult, please.”Corey: Right? I feel like the primary purpose there might very well be that when someone presents to your board and says, “All right, we've had this conversation with Accenture.” The response is not, “Who?” It's a brand awareness play, on some level. That said, you say you don't do a bunch traditional advertising, but honestly, I feel like you advertise—more successfully—than I do at The Duckbill Group, just by virtue of having a personality running the company, in your case.Now, your platform is for the moment, slightly larger than mine, but that's okay,k I have ambition and a tenuous grasp of reality and I'm absolutely going to get there one of these days. But there is something to be said for someone who has a track record of doing interesting things and saying interesting things, pulling a, “This is what I do and this is how I do it.” It almost becomes a personality-led marketing effort to some degree, doesn't it?Anil: I'm a little mindful of that, right, where I think—so a little bit of context and history: Glitch as a company is actually 20 years old. The product is only a few years old, but we were formerly called Fog Creek Software, co-founded by Joel Spolsky who a lot of folks will know from back in the day as Joel on Software blog, was extremely influential. And that company, under leadership of Joel and his co-founder Michael Pryor spun out Stack Overflow, they spun out Trello. He had created, you know, countless products over the years so, like, their technical and business acumen is off the charts.And you know, I was on the board of Stack Overflow from, really, those first days and until just recently when they sold, and you know, you get this insight into not just how do you build a developer community that is incredibly valuable, but also has a place in the ecosystem that is unique and persists over time. And I think that's something that was very, very instructive. And so when it came in to lead Glitch I, we had already been a company with a, sort of, visible founder. Joel was as well known as a programmer as it got in the world?Corey: Oh, yes.Anil: And my public visibility is different, right? I, you know, I was a working coder for many years, but I don't think that's what people see me on social media has. And so I think, I've been very mindful where, like, I'm thrilled to use the platform I have to amplify what was created on a Glitch. But what I note is it's always, “This person made this thing. This person made this app and it had this impact, and it got these results, or made this difference for them.”And that's such a different thing than—I don't ever talk about, “We added syntax highlighting in the IDE and the editor in the browser.” It's just never it right. And I think there are people that—I love that work. I mean, I love having that conversation with our team, but I think that's sort of the difference is my enthusiasm is, like, people are making stuff and it's cool. And that sort of is my lens on the whole world.You know, somebody makes whatever a great song, a great film, like, these are all things that are exciting. And the Glitch community's creations sort of feel that way. And also, we have other visible people on the team. I think of our sort of Head of Community, Jenn Schiffer, who's a very well known developer and her right. And you know, tons of people have read her writing and seen her talks over the years.And she and I talk about this stuff; I think she sort of feels the same way, which is, she's like, “If I were, you know, being hired by some cloud platform to show the latest primitives that they've deployed behind an API,” she's like, “I'd be miserable. Like, I don't want to do that in the world.” And I sort of feel the same way. But if you say, “This person who never imagined they would make an app that would have this kind of impact.” And they're going to, I think of just, like, the last couple of weeks, some of the apps we've seen where people are—it could be [unintelligible 00:11:53]. It could be like, “We made a Slack bot that finally gets this reporting into the right channel [laugh] inside our company, but it was easy enough that I could do it myself without asking somebody to create it even though I'm not technically an engineer.” Like, that's incredible.The other extreme, we have people that are PhDs working on machine learning that are like, “At the end of the day, I don't want to be responsible for managing and deploying. [laugh]. I go home, and so the fact that I can do this in create is really great.” I think that energy, I mean, I feel the same way. I still build stuff all the time, and I think that's something where, like, you can't fake that and also, it's bigger than any one person or one public persona or social media profile, or whatever. I think there's this bigger idea. And I mean, to that point, there are millions of developers on Glitch and they've created well over ten million apps. I am not a humble person, but very clearly, that's not me, you know? [laugh].Corey: I have the same challenge to it's, effectively, I have now a 12 employee company and about that again contractors for various specialized functions, and the common perception, I think, is that mostly I do all the stuff that we talk about in public, and the other 11 folks sort of sit around and clap as I do it. Yeah, that is only four of those people's jobs as it turns out. There are more people doing work here. It's challenging, on some level, to get away from the myth of the founder who is the person who has the grand vision and does all the work and sees all these things.Anil: This industry loves the myth of the great man, or the solo legend, or the person in their bedroom is a genius, the lone genius, and it's a lie. It's a lie every time. And I think one of the things that we can do, especially in the work at Glitch, but I think just in my work overall with my whole career is to dismantle that myth. I think that would be incredibly valuable. It just would do a service for everybody.But I mean, that's why Glitch is the way it is. It's a collaboration platform. Our reference points are, you know, we look at Visual Studio and what have you, but we also look at Google Docs. Why is it that people love to just send a link to somebody and say, “Let's edit this thing together and knock out a, you know, a memo together or whatever.” I think that idea we're going to collaborate together, you know, we saw that—like, I think of Figma, which is a tool that I love. You know, I knew Dylan when he was a teenager and watching him build that company has been so inspiring, not least because design was always supposed to be collaborative.And then you think about we're all collaborating together in design every day. We're all collaborating together and writing in Google Docs—or whatever we use—every day. And then coding is still this kind of single-player game. Maybe at best, you throw something over the wall with a pull request, but for the most part, it doesn't feel like you're in there with somebody. Certainly doesn't feel like you're creating together in the same way that when you're jamming on these other creative tools does. And so I think that's what's been liberating for a lot of people is to feel like it's nice to have company when you're making something.Corey: Periodically, I'll talk to people in the AWS ecosystem who for some reason appear to believe that Jeff Barr builds a lot of these services himself then writes blog posts about them. And it's, Amazon does not break out how many of its 1.2 million or so employees work at AWS, but I'm guessing it's more than five people. So yeah, Jeff probably only wrote a dozen of those services himself; the rest are—Anil: That's right. Yeah.Corey: —done by service teams and the rest. It's easy to condense this stuff and I'm as guilty of it as anyone. To my mind, a big company is one that has 200 people in it. That is not apparently something the world agrees with.Anil: Yeah, it's impossible to fathom an organization of hundreds of thousands or a million-plus people, right? Like, our brains just aren't wired to do it. And I think so we reduce things to any given Jeff, whether that's Barr or Bezos, whoever you want to point to.Corey: At one point, I think they had something like more men named Jeff on their board than they did women, which—Anil: Yeah. Mm-hm.Corey: —all right, cool. They've fixed that and now they have a Dave problem.Anil: Yeah [unintelligible 00:15:37] say that my entire career has been trying to weave out of that dynamic, whether it was a Dave, a Mike, or a Jeff. But I think that broader sort of challenge is this—that is related to the idea of there being this lone genius. And I think if we can sort of say, well, creation always happens in community. It always happens influenced by other things. It is always—I mean, this is why we talk about it in Glitch.When you make an app, you don't start from a blank slate, you start from a working app that's already on the platform and you're remix it. And there was a little bit of a ego resistance by some devs years ago when they first encountered that because [unintelligible 00:16:14] like, “No, no, no, I need a blank page, you know, because I have this brilliant idea that nobody's ever thought of before.” And I'm like, “You know, the odds are you'll probably start from something pretty close to something that's built before.” And that enabler of, “There's nothing new under the sun, and you're probably remixing somebody else's thoughts,” I think that sort of changed the tenor of the community. And I think that's something where like, I just see that across the industry.When people are open, collaborative, like even today, a great example is web browsers. The folks making web browsers at Google, Apple, Mozilla are pretty collaborative. They actually do share ideas together. I mean, I get a window into that because they actually all use Glitch to do test cases on different bugs and stuff for them, but you see, one Glitch project will add in folks from Mozilla and folks from Apple and folks from the Chrome team and Google, and they're like working together and you're, like—you kind of let down the pretense of there being this secret genius that's only in this one organization, this one group of people, and you're able to make something great, and the web is greater than all of them. And the proof, you know, for us is that Glitch is not a new idea. Heroku wanted to do what we're doing, you know, a dozen years ago.Corey: Yeah, everyone wants to build Heroku except the company that acquired Heroku, and here we are. And now it's—I was waiting for the next step and it just seemed like it never happened.Anil: But you know when I talked to those folks, they were like, “Well, we didn't have Docker, and we didn't have containerization, and on the client side, we didn't have modern browsers that could do this kind of editing experience, all this kind of thing.” So, they let their editor go by the wayside and became mostly deploy platform. And—but people forget, for the first year or two Heroku had an in-browser editor, and an IDE and, you know, was constrained by the tech at the time. And I think that's something where I'm like, we look at that history, we look at, also, like I said, these browser manufacturers working together were able to get us to a point where we can make something better.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: I do have a question for you about the nuts and bolts behind the scenes of Glitch and how it works. If I want to remix something on Glitch, I click the button, a couple seconds later it's there and ready for me to start kicking the tires on, which tells me a few things. One, it is certainly not using CloudFormation to provision it because I didn't have time to go and grab a quick snack and take a six hour nap. So, it apparently is running on computers somewhere. I have it on good authority that this is not just run by people who are very fast at assembling packets by hand. What does the infrastructure look like?Anil: It's on AWS. Our first year-plus of prototyping while we were sort of in beta and early stages of Glitch was getting that time to remix to be acceptable. We still wish it were faster; I mean, that's always the way but, you know, when we started, it was like, yeah, you did sit there for a minute and watch your cursor spin. I mean, what's happening behind the scenes, we're provisioning a new container, standing up a full stack, bringing over the code from the Git repo on the previous project, like, we're doing a lot of work, lift behind the scenes, and we went through every possible permutation of what could make that experience be good enough. So, when we start talking about prototyping, we're at five-plus, almost six years ago when we started building the early versions of what became Glitch, and at that time, we were fairly far along in maturity with Docker, but there was not a clear answer about the use case that we're building for.So, we experimented with Docker Swarm. We went pretty far down that road; we spent a good bit of time there, it failed in ways that were both painful and slow to fix. So, that was great. I don't recommend that. In fairness, we have a very unusual use case, right? So, Glitch now, if you talk about ten million containers on Glitch, no two of those apps are the same and nobody builds an orchestration infrastructure assuming that every single machine is a unique snowflake.Corey: Yeah, massively multi-tenant is not really a thing that people know.Anil: No. And also from a security posture Glitch—if you look at it as a security expert—it is a platform allowing anonymous users to execute arbitrary code at scale. That's what we do. That's our job. And so [laugh], you know, so your threat model is very different. It's very different.I mean, literally, like, you can go to Glitch and build an app, running a full-stack app, without even logging in. And the reason we enable that is because we see kids in classrooms, they're learning to code for the first time, they want to be able to remix a project and they don't even have an email address. And so that was about enabling something different, right? And then, similarly, you know, we explored Kubernetes—because of course you do; it's the default choice here—and some of the optimizations, again, if you go back several years ago, being able to suspend a project and then quickly sort of rehydrate it off disk into a running app was not a common use case, and so it was not optimized. And so we couldn't offer that experience because what we do with Glitch is, if you haven't used an app in five minutes, and you're not a paid member, who put that app to sleep. And that's just a reasonable—Corey: Uh, “Put the app to sleep,” as in toddler, or, “Put the app to sleep,” as an ill puppy.Anil: [laugh]. Hopefully, the former, but when we were at our worst and scaling the ladder. But that is that thing; it's like we had that moment that everybody does, which is that, “Oh, no. This worked.” That was a really scary moment where we started seeing app creation ramping up, and number of edits that people were making in those apps, you know, ramping up, which meant deploys for us ramping up because we automatically deploy as you edit on Glitch. And so, you know, we had that moment where just—well, as a startup, you always hope things go up into the right, and then they do and then you're not sleeping for a long time. And we've been able to get it back under control.Corey: Like, “Oh, no, I'm not succeeding.” Followed immediately by, “Oh, no, I'm succeeding.” And it's a good problem to have.Anil: Exactly. Right, right, right. The only thing worse than failing is succeeding sometimes, in terms of stress levels. And organizationally, you go through so much; technically, you go through so much. You know, we were very fortunate to have such thoughtful technical staff to navigate these things.But it was not obvious, and it was not a sort of this is what you do off the shelf. And our architecture was very different because people had looked at—like, I look at one of our inspirations was CodePen, which is a great platform and the community love them. And their front end developers are, you know, always showing off, “Here's this cool CSS thing I figured out, and it's there.” But for the most part, they're publishing static content, so architecturally, they look almost more like a content management system than an app-running platform. And so we couldn't learn anything from them about our scaling our architecture.We could learn from them on community, and they've been an inspiration there, but I think that's been very, very different. And then, conversely, if we looked at the Herokus of the world, or all those sort of easy deploy, I think Amazon has half a dozen different, like, “This will be easier,” kind of deploy tools. And we looked at those, and they were code-centric not app-centric. And that led to fundamentally different assumptions in user experience and optimization.And so, you know, we had to chart our own path and I think it was really only the last year or so that we were able to sort of turn the corner and have high degree of confidence about, we know what people build on Glitch and we know how to support and scale it. And that unlocked this, sort of, wave of creativity where there are things that people want to create on the internet but it had become too hard to do so. And the canonical example I think I was—those of us are old enough to remember FTPing up a website—Corey: Oh, yes.Anil: —right—to Geocities, or whatever your shared web host was, we remember how easy that was and how much creativity was enabled by that.Corey: Yes, “How easy it was,” quote-unquote, for those of us who spent years trying to figure out passive versus active versus ‘what is going on?' As far as FTP transfers. And it turns out that we found ways to solve for that, mostly, but it became something a bit different and a bit weird. But here we are.Anil: Yeah, there was definitely an adjustment period, but at some point, if you'd made an HTML page in notepad on your computer, and you could, you know, hurl it at a server somewhere, it would kind of run. And when you realize, you look at the coding boot camps, or even just to, like, teach kids to code efforts, and they're like, “Day three. Now, you've gotten VS Code and GitHub configured. We can start to make something.” And you're like, “The whole magic of this thing getting it to light up. You put it in your web browser, you're like, ‘That's me. I made this.'” you know, north star for us was almost, like, you go from zero to hello world in a minute. That's huge.Corey: I started participating one of those boot camps a while back to help. Like, the first thing I changed about the curriculum was, “Yeah, we're not spending time teaching people how to use VI in, at that point, the 2010s.” It was, that was a fun bit of hazing for those of us who were becoming Unix admins and knew that wherever we'd go, we'd find VI on a server, but here in the real world, there are better options for that.Anil: This is rank cruelty.Corey: Yeah, I mean, I still use it because 20 years of muscle memory doesn't go away overnight, but I don't inflict that on others.Anil: Yeah. Well, we saw the contrast. Like, we worked with, there's a group called Mouse here in New York City that creates the computer science curriculum for the public schools in the City of New York. And there's a million kids in public school in New York City, right, and they all go through at least some of this CS education. [unintelligible 00:24:49] saw a lot of work, a lot of folks in the tech community here did. It was fantastic.And yet they were still doing this sort of very conceptual, theoretical. Here's how a professional developer would set up their environment. Quote-unquote, “Professional.” And I'm like, you know what really sparks kids' interests? If you tell them, “You can make a page and it'll be live and you can send it to your friend. And you can do it right now.”And once you've sparked that creative impulse, you can't stop them from doing the rest. And I think what was wild was kids followed down that path. Some of the more advanced kids got to high school and realized they want to experiment with, like, AI and ML, right? And they started playing with TensorFlow. And, you know, there's collaboration features in Glitch where you can do real-time editing and a code with this. And they went in the forum and they were asking questions, that kind of stuff. And the people answering their questions were the TensorFlow team at Google. [laugh]. Right?Corey: I remember those days back when everything seemed smaller and more compact, [unintelligible 00:25:42] but almost felt like a balkanization of community—Anil: Yeah.Corey: —where now it's oh, have you joined that Slack team, and I'm looking at this and my machine is screaming for more RAM. It's, like, well, it has 128 gigs in it. Shouldn't that be enough? Not for Slack.Anil: Not for chat. No, no, no. Chat is demanding.Corey: Oh, yeah, that and Chrome are basically trying to out-ram each other. But if you remember the days of volunteering as network staff on Freenode when you could basically gather everyone for a given project in the entire stack on the same IRC network. And that doesn't happen anymore.Anil: And there's something magic about that, right? It's like now the conversations are closed off in a Slack or Discord or what have you, but to have a sort of open forum where people can talk about this stuff, what's wild about that is, for a beginner, a teenage creator who's learning this stuff, the idea that the people who made the AI, I can talk to, they're alive still, you know what I mean? Like, yeah, they're not even that old. But [laugh]. They think of this is something that's been carved in stone for 100 years.And so it's so inspiring to them. And then conversely, talking to the TensorFlow team, they made these JavaScript examples, like, tensorflow.js was so accessible, you know? And they're like, “This is the most heartwarming thing. Like, we think about all these enterprise use cases or whatever. But like, kids wanting to make stuff, like recognize their friends' photo, and all the vision stuff they're doing around [unintelligible 00:26:54] out there,” like, “We didn't know this is why we do it until we saw this is why we do it.”And that part about connecting the creative impulse from both, like, the most experienced, advanced coders at the most august tech companies that exist, as well as the most rank beginners in public schools, who might not even have a computer at home, saying that's there—if you put those two things together, and both of those are saying, “I'm a coder; I'm able to create; I can make something on the internet, and I can share it with somebody and be inspired by it,” like, that is… that's as good as it gets.Corey: There's something magic in being able to reach out to people who built this stuff. And honestly—you shouldn't feel this way, but you do—when I was talking to the folks who wrote the things I was working on, it really inspires you to ask better questions. Like when I'm talking to Dr. Venema, the author of Postfix and I'm trying to figure out how this thing works, well, I know for a fact that I will not be smarter than he is at basically anything in that entire universe, and maybe most beyond that, as well, however, I still want to ask a question in such a way that doesn't make me sound like a colossal dumbass. So, it really inspires you—Anil: It motivates you.Corey: Oh, yeah. It inspires you to raise your question bar up a bit, of, “I am trying to do x. I expect y to happen. Instead, z is happening as opposed to what I find the documentation that”—oh, as I read the documentation, discover exactly what I messed up, and then I delete the whole email. It's amazing how many of those things you never send because when constructing a question the right way, you can help yourself.Anil: Rubber ducking against your heroes.Corey: Exactly.Anil: I mean, early in my career, I'd gone through sort of licensing mishap on a project that later became open-source, and sort of stepped it in and as you do, and unprompted, I got an advice email from Dan Bricklin, who invented the spreadsheet, he invented VisiCalc, and he had advice and he was right. And it was… it was unreal. I was like, this guy's one of my heroes. I grew up reading about his work, and not only is he, like, a living, breathing person, he's somebody that can have the kindness to reach out and say, “Yeah, you know, have you tried this? This might work.”And it's, this isn't, like, a guy who made an app. This is the guy who made the app for which the phrase killer app was invented, right? And, you know, we've since become friends and I think a lot of his inspiration and his work. And I think it's one of the things it's like, again, if you tell somebody starting out, the people who invented the fundamental tools of the digital era, are still active, still building stuff, still have advice to share, and you can connect with them, it feels like a cheat code. It feels like a superpower, right? It feels like this impossible thing.And I think about like, even for me, the early days of the web, view source, which is still buried in our browser somewhere. And you can see the code that makes the page, it felt like getting away with something. “You mean, I can just look under the hood and see how they made this page and then I can do it too?” I think we forget how radical that is—[unintelligible 00:29:48] radical open-source in general is—and you see it when, like, you talk to young creators. I think—you know, I mean, Glitch obviously is used every day by, like, people at Microsoft and Google and the New York Timesor whatever, like, you know, the most down-the-road, enterprise developers, but I think a lot about the new creators and the people who are learning, and what they tell me a lot is the, like, “Oh, so I made this app, but what do I have to do to put it on the internet?”I'm like, “It already is.” Like, as soon as you create it, that URL was live, it all works. And their, like, “But isn't there, like, an app store I have to ask? Isn't there somebody I have to get permission to publish this from? Doesn't somebody have to approve it?”And you realize they've grown up with whether it was the app stores on their phones, or the cartridges in their Nintendo or, you know, whatever it was, they had always had this constraint on technology. It wasn't something you make; it's something that is given to you, you know, handed down from on high. And I think that's the part that animates me and the whole team, the community, is this idea of, like, I geek out about our infrastructure. I love that we're doing deploys constantly, so fast, all the time, and I love that we've taken the complexity away, but the end of the day, the reason why we do it, is you can have somebody just sort of saying, I didn't realize there was a place I could just make something put it in front of, maybe, millions of people all over the world and I don't have to ask anybody permission and my idea can matter as much as the thing that's made by the trillion-dollar company.Corey: It's really neat to see, I guess, the sense of spirit and soul that arises from a smaller, more, shall we say, soulful company. No disparagement meant toward my friends at AWS and other places. It's just, there's something that you lose when you get to a certain point of scale. Like, I don't ever have to have a meeting internally and discuss things, like, “Well, does this thing that we're toying with doing violate antitrust law?” That is never been on my roadmap of things I have to even give the slightest crap about.Anil: Right, right? You know, “What does the investor relations person at a retirement fund think about the feature that we shipped?” Is not a question that we have to answer. There's this joy in also having community that sort of has come along with us, right? So, we talk a lot internally about, like, how do we make sure Glitch stays weird? And, you know, the community sort of supports that.Like, there's no reason logically that our logo should be the emoji of two fish. But that kind of stuff of just, like, it just is. We don't question it anymore. I think that we're very lucky. But also that we are part of an ecosystem. I also am very grateful where, like… yeah, that folks at Google use Glitch as part of their daily work when they're explaining a new feature in Chrome.Like, if you go to web.dev and their dev portal teaches devs how to code, all the embedded examples go to these Glitch apps that are running, showing running code is incredible. When we see the Stripe team building examples of, like, “Do you want to use this new payment API that we made? Well, we have a Glitch for you.” And literally every day, they ship one that sort of goes and says, “Well, if you just want to use this new Stripe feature, you just remix this thing and it's instantly running on Glitch.”I mean, those things are incredible. So like, I'm very grateful that the biggest companies and most influential companies in the industry have embraced it. So, I don't—yeah, I don't disparage them at all, but I think that ability to connect to the person who'd be like, “I just want to do payments. I've never heard of Stripe.”Corey: Oh yeah.Anil: And we have this every day. They come into Glitch, and they're just like, I just wanted to take credit cards. I didn't know there's a tool to do that.Corey: “I was going to build it myself,” and everyone shrieks, “No, no. Don't do that. My God.” Yeah. Use one of their competitors, fine,k but building it yourself is something a lunatic would do.Anil: Exactly. Right, right. And I think we forget that there's only so much attention people can pay, there's only so much knowledge they have.Corey: Everything we say is new to someone. That's why I always go back to assuming no one's ever heard of me, and explain the basics of what I do and how I do it, periodically. It's, no one has done all the mandatory reading. Who knew?Anil: And it's such a healthy exercise to, right, because I think we always have that kind of beginner's mindset about what Glitch is. And in fairness, I understand why. Like, there have been very experienced developers that have said, “Well, Glitch looks too colorful. It looks like a toy.” And that we made a very intentional choice at masking—like, we're doing the work under the hood.And you can drop down into a terminal and you can do—you can run whatever build script you want. You can do all that stuff on Glitch, but that's not what we put up front and I think that's this philosophy about the role of the technology versus the people in the ecosystem.Corey: I want to thank you for taking so much time out of your day to, I guess, explain what Glitch is and how you view it. If people want to learn more about it, about your opinions, et cetera. Where can they find you?Anil: Sure. glitch.com is easiest place, and hopefully that's a something you can go and a minute later, you'll have a new app that you built that you want to share. And, you know, we're pretty active on all social media, you know, Twitter especially with Glitch: @glitch. I'm on as @anildash.And one of the things I love is I get to talk to folks like you and learn from the community, and as often as not, that's where most of the inspiration comes from is just sort of being out in all the various channels, talking to people. It's wild to be 20-plus years into this and still never get tired of that.Corey: It's why I love this podcast. Every time I talk to someone, I learn something new. It's hard to remain too ignorant after you have enough people who've shared wisdom with you as long as you can retain it.Anil: That's right.Corey: Thank you so much for taking the time to speak with me.Anil: So, glad to be here.Corey: Anil Dash, CEO of Gletch—or Glitch as he insists on calling it. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment telling me how your small team at AWS is going to crush Glitch into the dirt just as soon as they find a name that's dumb enough for the service.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

god ceo new york amazon spotify community tiktok head new york city google ai apple phd office data microsoft professional twitch nfts bs hamilton atlantic software discord medium cloud nintendo jeff bezos windows huffington post chat ram slack wired mouse sxsw api cio cs chrome coding screaming mm accenture aws ml barr linux github mero aol glitch stripe lin manuel miranda my god devops javascript html trello google docs businessweek contemporary art css digital strategies dns ide mozilla docker git kubernetes figma anil irc gitlab ftp obama white house gawker stack overflow 5x unix mysql imovie desus electronic frontier foundation final cut pro ssh vs code tensorflow breaching markup visual studio redis teleport heroku new museum geocities donorschoose grafana oracle cloud visual basic jupyter notebooks corey quinn codepen anil dash venema olap cloudformation visicalc joel spolsky oltp freenode amazon redshift project include michael pryor duckbill group amazon aurora fog creek software movable type society research institute jeff barr typepad dan bricklin jenn schiffer chief cloud economist aws management console twetch postfix last week in aws humblepod

35: Halide - Sebastiaan de With & Ben Sandofsky

Launched

Play Episode Listen Later Dec 21, 2021 73:53

Sebastiaan de With & Ben Sandofsky join to show to talk about building the outstanding camera app Halide. Links & Show Notes Sebastiaan's Twitter (https://twitter.com/sdw) Ben's Twitter (https://twitter.com/sandofsky) Halide (app) (https://halide.cam) Spectre (app) (https://spectre.cam) Lux Blog (https://lux.camera) Halide Mark II (https://lux.camera/pro-camera-action-introducing-halide-mark-ii/) Sommer Panage (https://twitter.com/Sommer) Linda Dong (https://twitter.com/lindadong) Serenity Caldwell (https://twitter.com/settern) Jamie Zawinski (https://www.jwz.org/blog/) Joel Spolsky (https://www.joelonsoftware.com) Peter Norvig (https://norvig.com) More Launched Website - launchedfm.com (https://launchedfm.com) Twitter - @LaunchedFM (https://twitter.com/launchedfm) Reddit - /r/LaunchedFM (https://www.reddit.com/r/LaunchedFM/)

iphone reddit app photography ios ipads camera spectre sebastiaan halide peter norvig joel spolsky serenity caldwell jamie zawinski

An Abridged History of Free And Open Source Software

The History of Computing

Play Episode Listen Later Nov 24, 2021 22:34

In the previous episodes, we looked at the rise of patents and software and their impact on the nascent computer industry. But a copyright is a right. And that right can be given to others in whole or in part. We have all benefited from software where the right to copy was waved and it's shaped the computing industry as much, if not more, than proprietary software. The term Free and Open Source Software (FOSS for short) is a blanket term to describe software that's free and/or whose source code is distributed for varying degrees of tinkeration. It's a movement and a choice. Programmers can commercialize our software. But we can also distribute it free of copy protections. And there are about as many licenses as there are opinions about what is unique, types of software, underlying components, etc. But given that many choose to commercialize their work products, how did a movement arise that specifically didn't? The early computers were custom-built to perform various tasks. Then computers and software were bought as a bundle and organizations could edit the source code. But as operating systems and languages evolved and businesses wanted their own custom logic, a cottage industry for software started to emerge. We see this in every industry - as an innovation becomes more mainstream, the expectations and needs of customers progress at an accelerated rate. That evolution took about 20 years to happen following World War II and by 1969, the software industry had evolved to the point that IBM faced antitrust charges for bundling software with hardware. And after that, the world of software would never be the same. The knock-on effect was that in the 1970s, Bell Labs pushed away from MULTICS and developed Unix, which AT&T then gave away as compiled code to researchers. And so proprietary software was a growing industry, which AT&T began charging for commercial licenses as the bushy hair and sideburns of the 70s were traded for the yuppy culture of the 80s. In the meantime, software had become copyrightable due to the findings of CONTU and the codifying of the Copyright Act of 1976. Bill Gates sent his infamous “Open Letter to Hobbyists” in 1976 as well, defending the right to charge for software in an exploding hobbyist market. And then Apple v Franklin led to the ability to copyright compiled code in 1983. There was a growing divide between those who'd been accustomed to being able to copy software freely and edit source code and those who in an up-market sense just needed supported software that worked - and were willing to pay for it, seeing the benefits that automation was having on the capabilities to scale an organization. And yet there were plenty who considered copyright software immoral. One of the best remembered is Richard Stallman, or RMS for short. Steven Levy described Stallman as “The Last of the True Hackers” in his epic book “Hackers: Heroes of the Computer Revolution.” In the book, he describes the MIT Stallman joined where there weren't passwords and we didn't yet pay for software and then goes through the emergence of the LISP language and the divide that formed between Richard Greenblatt, who wanted to keep The Hacker Ethic alive and those who wanted to commercialize LISP. The Hacker Ethic was born from the young MIT students who freely shared information and ideas with one another and help push forward computing in an era they thought was purer in a way, as though it hadn't yet been commercialized. The schism saw the death of the hacker culture and two projects came out of Stallman's technical work: emacs, which is a text editor that is still included freely in most modern Unix variants and the GNU project. Here's the thing, MIT was sitting on patents for things like core memory and thrived in part due to the commercialization or weaponization of the technology they were producing. The industry was maturing and since the days when kings granted patents, maturing technology would be commercialized using that system. And so Stallman's nostalgia gave us the GNU project, born from an idea that the industry moved faster in the days when information was freely shared and that knowledge was meant to be set free. For example, he wanted the source code for a printer driver so he could fix it and was told it was protected by an NDAQ and so couldn't have it. A couple of years later he announced GNU, a recursive acronym for GNU's Not Unix. The next year he built a compiler called GCC and the next year released the GNU Manifesto, launching the Free Software Foundation, often considered the charter of the free and open source software movement. Over the next few years as he worked on GNU, he found emacs had a license, GCC had a license, and the rising tide of free software was all distributed with unique licenses. And so the GNU General Public License was born in 1989 - allowing organizations and individuals to copy, distribute, and modify software covered under the license but with a small change, that if someone modified the source, they had to release that with any binaries they distributed as well. The University of California, Berkley had benefited from a lot of research grants over the years and many of their works could be put into the public domain. They had brought Unix in from Bell Labs in the 70s and Sun cofounder and Java author Bill Joy worked under professor Fabry, who brought Unix in. After working on a Pascal compiler that Unix coauthor Ken Thompson left for Berkeley, Joy and others started working on what would become BSD, not exactly a clone of Unix but with interchangeable parts. They bolted on the OSI model to get networking and through the 80s as Joy left for Sun and DEC got ahold of that source code there were variants and derivatives like FreeBSD, NetBSD, Darwin, and others. The licensing was pretty permissive and simple to understand: Copyright (c) . All rights reserved. Redistribution and use in source and binary forms are permitted provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other materials related to such distribution and use acknowledge that the software was developed by the . The name of the may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED ``AS IS AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. By 1990 the Board of Regents at Berkley accepted a four clause BSD license that spawned a class of licenses. While it's matured into other formats like a 0 clause license it's one of my favorites as it is truest to the FOSS cause. And the 90s gave us the Apache License, from the Apache Group, loosely based on the BSD License and then in 2004 leaning away from that with the release of the Apache License 2 that was more compatible with the GPL license. Given the modding nature of Apache they didn't require derivative works to also be open sourced but did require leaving the license in place for unmodified parts of the original work. GNU never really caught on as an OS in the mainstream, although a collection of tools did. The main reason the OS didn't go far is probably because Linus Torvalds started releasing prototypes of his Linux operating system in 1991. Torvalds used The GNU General Public License v2, or GPLv2 to license his kernel, having been inspired by a talk given by Stallman. GPL 2 had been released in 1991 and something else was happening as we turned into the 1990s: the Internet. Suddenly the software projects being worked on weren't just distributed on paper tape or floppy disks; they could be downloaded. The rise of Linux and Apache coincided and so many a web server and site ran that LAMP stack with MySQL and PHP added in there. All open source in varying flavors of what open source was at the time. And collaboration in the industry was at an all-time high. We got the rise of teams of developers who would edit and contribute to projects. One of these was a tool for another aspect of the Internet, email. It was called popclient, Here Eric S Raymond, or ESR for short, picked it up and renamed it to fetchmail, releasing it as an open source project. Raymond presented on his work at the Linux Congress in 1997, expanded that work into an essay and then the essay into “The Cathedral and the Bazaar” where bazaar is meant to be like an open market. That inspired many to open source their own works, including the Netscape team, which resulted in Mozilla and so Firefox - and another book called “Freeing the Source: The Story of Mozilla” from O'Reilly. By then, Tim O'Reilly was a huge proponent of this free or source code available type of software as it was known. And companies like VA Linux were growing fast. And many wanted to congeal around some common themes. So in 1998, Christine Peterson came up with the term “open source” in a meeting with Raymond, Todd Anderson, Larry Augustin, Sam Ockman, and Jon “Maddog” Hall, author of the first book I read on Linux. Free software it may or may not be but open source as a term quickly proliferated throughout the lands. By 1998 there was this funny little company called Tivo that was doing a public beta of a little box with a Linux kernel running on it that bootstrapped a pretty GUI to record TV shows on a hard drive on the box and play them back. You remember when we had to wait for a TV show, right? Or back when some super-fancy VCRs could record a show at a specific time to VHS (but mostly failed for one reason or another)? Well, Tivo meant to fix that. We did an episode on them a couple of years ago but we skipped the term Tivoization and the impact they had on GPL. As the 90s came to a close, VA Linux and Red Hat went through great IPOs, bringing about an era where open source could mean big business. And true to the cause, they shared enough stock with Linus Torvalds to make him a millionaire as well. And IBM pumped a billion dollars into open source, with Sun moving to open source openoffice.org. Now, what really happened there might be that by then Microsoft had become too big for anyone to effectively compete with and so they all tried to pivot around to find a niche, but it still benefited the world and open source in general. By Y2K there was a rapidly growing number of vendors out there putting Linux kernels onto embedded devices. TiVo happened to be one of the most visible. Some in the Linux community felt like they were being taken advantage of because suddenly you had a vendor making changes to the kernel but their changes only worked on their hardware and they blocked users from modifying the software. So The Free Software Foundation updated GPL, bundling in some other minor changes and we got the GNU General Public License (Version 3) in 2006. There was a lot more in GPL 3, given that so many organizations were involved in open source software by then. Here, the full license text and original copyright notice had to be included along with a statement of significant changes and making source code available with binaries. And commercial Unix variants struggled with SGI going bankrupt in 2006 and use of AIX and HP-UX Many of these open source projects flourished because of version control systems and the web. SourceForge was created by VA Software in 1999 and is a free service that can be used to host open source projects. Concurrent Versions System, or CVS had been written by Dick Grune back in 1986 and quickly became a popular way to have multiple developers work on projects, merging diffs of code repositories. That gave way to git in the hearts of many a programmer after Linus Torvalds wrote a new versioning system called git in 2005. GitHub came along in 2008 and was bought by Microsoft in 2018 for 2018. Seeing a need for people to ask questions about coding, Stack Overflow was created by Jeff Atwood and Joel Spolsky in 2008. Now, we could trade projects on one of the versioning tools, get help with projects or find smaller snippets of sample code on Stack Overflow, or even Google random things (and often find answers on Stack Overflow). And so social coding became a large part of many a programmers day. As did dependency management, given how many tools are used to compile a modern web app or app. I often wonder how much of the code in many of our favorite tools is actually original. Another thought is that in an industry dominated by white males, it's no surprise that we often gloss over previous contributions. It was actually Grace Hopper's A-2 compiler that was the first software that was released freely with source for all the world to adapt. Sure, you needed a UNIVAC to run it, and so it might fall into the mainframe era and with the emergence of minicomputers we got Digital Equipment's DECUS for sharing software, leading in part to the PDP-inspired need for source that Stallman was so adamant about. General Motors developed SHARE Operating System for the IBM 701 and made it available through the IBM user group called SHARE. The ARPAnet was free if you could get to it. TeX from Donald Knuth was free. The BASIC distribution from Dartmouth was academic and yet Microsoft sold it for up to $100,000 a license (see Commodore ). So it's no surprise that people avoided paying upstarts like Microsoft for their software or that it took until the late 70s to get copyright legislation and common law. But Hopper's contributions were kinda' like open source v1, the work from RMS to Linux was kinda' like open source v2, and once the term was coined and we got the rise of a name and more social coding platforms from SourceForge to git, we moved into a third version of the FOSS movement. Today, some tools are free, some are open source, some are free as in beer (as you find in many a gist), some are proprietary. All are valid. Today there are also about as many licenses as there are programmers putting software out there. And here's the thing, they're all valid. You see, every creator has the right to restrict the ability to copy their software. After all, it's their intellectual property. Anyone who chooses to charge for their software is well within their rights. Anyone choosing to eschew commercialization also has that right. And every derivative in between. I wouldn't judge anyone based on any model those choose. Just as those who distribute proprietary software shouldn't be judged for retaining their rights to do so. Why not just post things we want to make free? Patents, copyrights, and trademarks are all a part of intellectual property - but as developers of tools we also need to limit our liability as we're probably not out there buying large errors and omissions insurance policies for every script or project we make freely available. Also, we might want to limit the abuse of our marks. For example, Linus Torvalds monitors the use of the Linux mark through the Linux Mark Institute. Apparently some William Dell Croce Jr tried to register the Linux trademark in 1995 and Torvalds had to sue to get it back. He provides use of the mark using a free and perpetual global sublicense. Given that his wife won the Finnish karate championship six times I wouldn't be messing with his trademarks. Thank you to all the creators out there. Thank you for your contributions. And thank you for tuning in to this episode of the History of Computing Podcast. Have a great day.

tv university california history google apple internet board microsoft mit world war ii sun os basic ibm bill gates berkeley vhs ipo copyright att pascal finnish cathedrals linux java cvs github lamp general motors bazaar dartmouth freeing apache open letters patents firefox commodore programmers php mozilla red hat tex regents aix foss stack overflow gcc unix netscape mysql osi open source software abridged rms tivo bell labs pdp redistribution lisp vcrs gpl bsd gnu esr grace hopper arpanet linus torvalds freebsd richard stallman sgi fabry hobbyists steven levy stallman todd anderson ken thompson free software foundation jeff atwood computer revolution univac joel spolsky donald knuth torvalds sourceforge bill joy christine peterson hackers heroes netbsd digital equipment apache license gnu general public license ndaq gplv2

95: Easier Software Integrations with Michael Zuercher of Prismatic

Constant Variables

Play Episode Listen Later Nov 9, 2021 51:25

Getting data to talk is harder than it should be. That's why Michael Zuercher co-founded Prismatic, a complete embedded iPaaS (Integration Platform as a Service) solution for B2B software teams. Michael joins the show to chat about why software companies should use an iPaaS provider over building an integration internally, what he's taken away from growing a startup during a pandemic, why rewriting code is often better than starting from scratch, and what makes acquisitions work. **Show Links** Things You Should Never Do by Joel Spolsky | https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ Prismatic Website | https://prismatic.io/ Rate and review the show on Apple Podcasts | https://constantvariables.co/review Connect with Tim Bornholdt on LinkedIn | https://www.linkedin.com/in/timbornholdt/ Full show notes and transcript | https://constantvariables.co Chat with The Jed Mahonis Group about your app dev questions | https://jmg.mn Are you an iOS, Android, or Rails developer? Visit the JMG Careers Page | https://jmg.mn/careers

service software android ios b2b integration easier chat rails prismatic ipaas joel spolsky zuercher tim bornholdt jed mahonis group

[Weekend Drop] Temporal: React for the Backend

The Swyx Mixtape

Play Episode Listen Later Oct 9, 2021 26:31

Video: https://youtu.be/Cxaf8E00GMMSlides: https://docs.google.com/presentation/d/1sJSqNy-t-kVxzrWlqMTp_03nI7Zo8Znr7k0f0C6L9ig/edit?usp=sharingTimestamps:[00:00:00] Intro[00:02:17] Part 1 - Components: Code Organization for Real Apps [00:04:26] What we learned from React [00:07:46] Part 2 - Architecture: Choreography vs Orchestration [00:13:05] Retries and Timeouts [00:14:37] Part 3 - Time: React vs Temporal[00:16:34] Elevator Pitch [00:17:13] Programming Model [00:18:44] Comparing React and Temporal Principles [00:19:11] Live Demo: Amazon One Click Button [00:23:49] Talk Recap [00:24:16] React and Temporal Full Comparison [00:24:42] Conclusion: EnablementTranscript [00:00:00] Once again, I want to thank you all for tuning in and joining, React New York 2021 without further ado, I'll pass it on to Shawn. All right, so hi everyone. Hello, React new York. It is my home town in the U S and I miss everyone back in New York. I am currently based in Seattle, but I'm here to talk about React for the Backend. In 2020 I actually thought that I had given my last React talk because I was all tapped out. I had said everything I wanted to say, and then React New York came by and said, do you want to speak? And I was like, oh, I really wanted to speak for React New York. So here's my presentation about what I've been working on and what I think the parallels have been for React. And I think there's some generalizable lessons, even if you don't end up using Temporal. So, the inspiration for this talk came from Guillermo Rauch, the creator of Next.js. And he was the first person to point out that Temporal.io, does to backend and infra what React did to frontend. Temporal engine is quite complex, much like React, but the surface exposed to developers a beautiful render function and I'm a bit upset because he realized there's before me and I have been working on Temporal for a few months now. So important caveats before I start this talk. What I'm presenting to you is alpha for TypeScript. Temporal is typically a goal or Java based application, but we're developing TypeScript and hopefully launching it soon. And then finally "React for the backend" is an analogy, not a design goal. The way I treat this is like, it's a, it's basically like crabs. And one of the most entertaining facts that I've ever found is that nature has apparently tried to evolve crabs five independent times. And in fact, there's a word in evolutionary biology for it called Carcinization. And of course, this is really good for a lot of memes. So tired convergent evolution is not uncommon, especially when species have similar selecting pressures in their environments, wired. Everything is Crab. And perhaps everything is React, because we have similar design space problems. So I'll tell a little bit of the story through three parts there's Components, and we'll tell it through the story of Uber, talk about architecture, we'll talk through the story of YouTube, and Time will tell you through the story of Amazon. So a lot to cover, I'm going to try to go really fast. Don't worry. I'll share the slides on my Twitter later on. Okay. [00:02:17] Part 1 - Components: Code Organization for Real Apps So part one is about components. You see this a lot on YouTube. Probably you're watching now on YouTube or live streaming. And yeah, you know, like three hour live stream and that's it. Very cool. I think we, we know how to break things down and React has really helped us be more productive by being able to break things down into the components and knowing how to compose them together in a predictable way. But there's a lot of things unanswered in things like this in, in full stack, clones of major well-known apps, which is the hard parts. What like a typical Uber trip, we'll have all these steps like search pricing match. Pick-up drop-off rating tipping, payment, email, uh, and so on and so forth. And typically the naive way of organizing all this is basically one after the other, right? Like this is search goes to pricing, goes to matching, goes to pick upgoes to dropoff goes to rating goes to tipping goes to payment, goes to email, imagine that these are all managed by separate teams and scaled independently. Then you realize, like, this is only the happy path. Then you have to throw in a whole bunch of things that can happen along the way. An Uber trip is basically a long running process with humans in the loop and humans are very, very messy by nature. So how would you write an Uber clone? good luck with a lot of data technologies that you would typically reach for just naively, because you will have to discover all these systems and all these use cases and edge cases along the way. So when people say full stack, they often really mean like this half drawn horse meme. I think this is particularly funny so I take every opportunity I can get to show it, but to be honest, a lot of us front end developers are probably the other way the half-drawn Dragon where we're frontend a very good and in the backend, we'll just like, you know, stick some stuff on Firebase and something. And in reality, if you look at the backend systems, most companies, especially at scale, go towards some form of very complex micro service, system. I don't have the chart for Uber, but Hail-0 is probably a good comparison. Netflix, Twitter, and It's not really avoidable. If you want to scale a company to any significant size, you probably have to break them up into independent services because you're going to ship your org chart anyway. [00:04:26] What we learned from React The thing I realized as a React developer, as a front end developer, is that actually we had a pretty good run in the past seven, eight years of React in terms of the fact that front end developers know how to organize code at least in terms of the component level. So we moved from the jQuery era where everything was just kind of spaghetti all over the place to at least something more organized where event handlers are strongly tied, locally tied with renders, but essentially managed by React's runtime. So a few key lessons from React that I personally draw [00:05:00] is that you want to have a component and a renderer model. Like, so essentially the user or the developer writes components. And then the react core team writes the render and that handles a lot of the boilerplate that you might typically forget. And this is everything to do with on mounting or having local states. And it gives you a very nice, non-leaky abstraction that you can write. Second, you can also guarantee work and correctness, which is originally what drew Jordan walk to make something like React because he was working on Facebook messenger and there was a lot of inconsistent state within Facebook manager because of the spaghetti code. So correctness, meaning that we embrace functional programming to produce a virtual DOM view is a pure function of state. If you look at the old enough React talks, you will see a lot of v = f(d), so view as a pure function of data. And finally the programming model. We like to say that it's just JavaScript. There's no custom syntax with templating syntax to learn. I think all these three lessons , there are actually a lot more, but all of these three lessons are where I'm going to focus on for this talk. And I think whenever you tackle any programming paradigm, any framework, any design question, you might want to run it through some of these ideas. So whenever I talk about React principles, I always like to bring up the fact that there's this often overlooked repo called react-basic. And it's actually in the official React organization on GitHub. And this is Sebastian Markbage, who is the tech lead of React. And he wrote down six years ago, his principles on what he thinks makes up React on a fundamental basis? No, JSX just like, what are the principles that we're designing for? We are designing for a simple, pure transformation, abstraction, composition, state, memoization. The words that he uses are very theoretical sometimes, but you feel it every single day when you write React. So there's a lot of things else apart from that, that reacts has done for front end programming. Apart from deterministic renders, we have useState with a reduction of boiler plate with unmounting, child components in con in the very careful design composition, um, side effects where, you know, we have used effect or use memo. And actually a lot of people don't know. I don't, I forget my source. I think it's Sophie Alpert, but, one-third of the React code base is actually just normalization of events across browsers. So you don't even have to worry about it. And creating synthetic events for that. They also produce a dev tool and manage a central scheduler and obviously the success of React over the past five, six years has really shown Testament to how great all these decisions have been. If you want to learn more about the talks that I've done and my perspectives on some of these React principles, I've done three talks. One is at React Rally. The second at JSConf and the third, ,at React Summit. So you can check out my YouTube for more conversations on that. I don't have time here. Okay. [00:07:46] Part 2 - Architecture: Choreography vs Orchestration So that was part one where we talked about Components and the React revolution. So part two, we're going to talk about architecture. So a bit, one level higher than just components. And I'm going to motivate this question with a question of how would you write YouTube. And again, if you look on YouTube for how to write YouTube tutorials, you can get full-stack clones of YouTube, which is pretty impressive, you know, write YouTube in three hours using Firebase. That's very impressive. Unfortunately the hard parts of YouTube also come in. And there are a bunch of Googlers actually who actually went and interviewed YouTube engineers on how YouTube works on the backend. There's a bunch of work that goes on in the background. So you need to upload your file. You need to analyze for metadata. You need to split it up into chunks. You need to process these chunks in parallel, and then you need to stitch it back. And by the way, processing, you have to produce an array of formats, right? From like, 240 P to like 1400 P or something like that. And then you have to stitch all these chunks back into the continuous videos that you actually see in stream. You need to notify subscribers, you need to produce automatic captions and you need to produce thumbnails. And that is again, just the happy path. Right. So, what about all these other features? It's. For example, YouTube premiere is a scheduled release of a YouTube video or feeding into the recommendation algorithm. That must be the most craziest batch job in the world. And you need to scale this process, whatever, whatever you design for 30,000 hours of video uploaded every hour. That's the sheer amount of volume that's going on YouTube today, which is just insane. Like, like any design that you make at scale is going to break in some respect. So I think, I think that's, that's really interesting to consider. And I learned about this actually, and I thought more about this because I interviewed one of our users who is Descript (hi! I'm editing this transcript in Descript rn lol). Descript is a audio transcription platform and their entire business is transcribing audio and then making it easy for you to edit audio. I do it for my podcast every single day and millions of people use it. I think it's really cool. So their problem was that when a user hits transcribe, it kicks off asynchronous multi-stage and parallelized process that involves reading, encoding audio, chunk splitting. external API calls, merging results that may potentially arrive out of order and then verifying their alignment. So there's a lot of [00:10:00] nuance here that can get really tricky. And if any part of the process fails, you need to try it again. So, this is typically the kind of architectures that people build up incrementally over time, as they discover all these use cases and then find holes and patch them because it's too late to rewrite something. There's a lot of decisions that goes into here. And this is normal. This is natural. I think you run into basically the eight fallacies of distributed computing, which has actually discussed or discovered back in 1994 by people at Sun Microsystems. I love these cartoons but it can be a little bit hard to read. So here's a more organized version of them. At the bare minimum, don't forget distributed computing fallacy number one, which is that the network may or may not be reliable or compute may or may not be reliable. So, what that means in practice is that when you're calling system a, B, C, D E F G you may actually need to introduce hardening layers because at every point and you cross system boundaries, you have a chance of failure and that multiplies exponentially, as you have more and more services tied up in your systems like we saw for the Uber example, like we saw for the YouTube example. You need to add in timeouts and retries. And what that means is that you need to persist the number of times you timed out, when you timed out, what jobs you timed up. So you need a database every single time, and then you need a scheduler or a timer to say when the next time is going out, I'm going to try this again. And you need to write this for every service. If the ma the maintainer for every service needs to maintain both the code and the infrastructure for this. This is a lot of how I was talking about things when I was exploring the serverless world. So here's a real life example from the AWS blog where they said that you were using dead letter queues to replay messages when such things as failures occur. This is a fine looking example until you try to scale it. And again it looks like a complete mess, complete track, and it's very hard to keep in your head, and pretty soon when you're explaining this to your CTO you look like the Pepe Silvia meme. So the solution that I found is really to have a central orchestrator, right? Instead of every single system maintainer writing their own API hardening layer, which is a production requirements, as you find more and more of these bugs, you should centralize it with a centralized team that takes care of the orchestration of all these different services. And that's in the business, what we call choreography, which is A to B to C versus orchestration, which is a central orchestrator coordinating the dance between AB and C, and then storing both the infrastructure and the code for the scheduler and the database. So there's a really good article on this by Yan Cui in the burningmonk.com so I highly recommend checking it out where he talks about choreography versus orchestration, with real life examples that people use in AWS, but also it's not specific to any cloud. It's a architecture design pattern, which I think fundamentally, if you start off with this, it's really hard to rearchitect to this. I mean, it's, it's possible because people are doing it, but also it's a conscious, architectural choice that you might not know that you're making if you don't know about it. So, I guess a lot of my message here is to tell you that orchestration is a thing. [00:13:05] Retries and Timeouts Also, so you want to declaratively put into your framework retries and timeouts, so for example, this is actually our API. You want to be able to say, all right, here's the default retry policy. Whenever I fire off an activity, an activity is just like an external API call, for example. So when I fire up an activity, I want it to be retried every second. If it fails, I need a backoff coefficient, like exponential backoff. This is very similar to the TCP protocol so that if the endpoint is failing or getting rate limited, I don't keep retrying, and then building up a DDoS attack on myself, I actually back off and put more and more intervals in between until some maximum interval, let's say a hundred seconds. And then I give myself a maximum attempt, so I can say like, all right. I don't want any retries. I can just say have a maximum attempt of one. Or let's say, I want a linear back off and not an exponential for whatever reason. And I want to try to a maximum of five times - you want to have this all declarative so that you can tweak this as you understand your system and you scale your system. Right? So I think this is a really interesting programming model that just puts retries into the code that you write. And that's only possible when you have your centralized orchestrator, no matter what system, not just Temporal. Okay. So the case that I'm making is really for choreography versus orchestration. And I, the analogy that I make for front end versus the back end is that it's kind of like vanilla or jQuery versus react. React has a react as the central orchestrator, orchestrating all the components. And I think that's a really interesting architectural analogy that you can make and learn from React. All right. [00:14:37] Part 3 - Time Part three - Time. I'm doing very good on time. I think better than I thought, which means that we'll have time for a live demo, which is really awesome. So let's talk a little bit about Temporal. [00:14:45] What is Temporal? What is Temporal? Temporal is the open source platform for orchestrating highly reliable mission-critical applications at scale. I love talking a little bit about the history, the reason because our CEO started at Amazon as the tech lead for what became Amazon SQS. Our [00:15:00] CTO was at Microsoft and it was the principal architect of the Durable Task Framework, which became a Microsoft's version of Durable Functions, and then finally they joined Uber and worked on Cadence, which is the open-source version of their workflow orchestration platform and Cadence became so popular that they spun out and became Temporal. And since then it's been adopted by a lot of well-known household name companies, especially in the developer world. There are a lot of people hiring for Temporal developers, which I really like to see because it's not just being used, but also it's creating jobs for people and it's becoming a desirable skillset. And most recently last week we had Netflix presenting about how they used Temporal for their CI/CD. Temporal has three components or produces three products that are used in sync. The main star is Temporal server, which is comparable to the React runtime that you might see, then there's Devtools, which is the UI that you might want to inspect the state of things. And then the SDK is, which is what you use to code. So I think all those are really comparable to what we have in React and having been in the React world for while, like, it's really amazing to see the analogies that we have. We have exactly the same thing. For me, the really sort of the seal of approval comes from Mitchell Hashimoto who, created Hashi Corp, saying that without Temporal, we would have spent a significant amount of time rebuilding Temporal, which actually to me is the best form of validation because Mitchell is one of the best developers in distributed systems and he says it's hard and he says it does it well. All right. Enough social proof you want actual facts? I would just give it straight to you. [00:16:34] Elevator Pitch So because your workloads like the YouTube encoding, or like the Uber journey and this technology was developed at Uber i s long running and it ties together multiple services. You want to standardize timeouts and retries and you want to make it easy for every team to have production grade retries and timeouts. Because this work is so important. You must never drop any work. You must log all progress. In other words, you must use event sourcing. And then finally, because this work is so complex, you want to use generic programming languages, instead of Domain specific languages. So you want to model a dynamic, asynchronous logic, and then you want to reuse, test, version and migrated it. So that's the pitch in one screen. But I'll just break it down for what it means, and then we'll go into a demo. [00:17:13] Programming Model So to me, The, the closest analogy to React is the programming model, because React spends a lot of time on API design and in the workflow orchestration world there are a lot of JSON or DAG based domain specific languages. So you, you write a bunch of JSON or you do boxes and arrows boxes and arrows boxes and arrows, sometimes you've even write XML, which is very interesting as well. What I find with all these is that they're actually really good for manipulating visually. But they get very tricky when you need to do programming language constructs, like variables, functions, loops, branching statements and all the things that we've invented in programming languages over the past few years. So if you use "just JavaScript" or "just programming languages", you have all the tooling available. You can use all the libraries that are available. You can use all the testing and code version, quality controls available. If you write your own, you have to rebuild all this dev tooling from scratch for yourself. So that's essentially what this is. Here's an example from one of the big clouds where this is their workflow orchestrator model, where you write Jason and it's really hard. It actually goes off the screen and I couldn't really fit everything on one screen. And with Temporal literal just JavaScript you call an endpoint you use that the result of that end point to call other end points, for example. It's a very simple example, but in built here is default retry policies that have been worked out. So both of these handle reliability on rails, it's just, we differ in the programming model and the engineering that it takes to maintain one of these SDKs is I'm learning. It's very, very immense. So it's really interesting. [00:18:44] Comparing React and Temporal Principles So, again, back to the core principles that we talked about early on from React. React d ecided on using a framework, decided on correctness and decided on a programming model, and Temporal, in a very similar way. The developer writes workflows and the Temporal core team writes the orchestrator, which is Temporal server. In terms of correctness, React insists on functional programming, Temporal insists on event sourcing in deterministic workflows and then programming model, you want "just JavaScript" or just programming languages, not any custom DSL syntax. [00:19:11] Live Demo: Amazon One Click Button So the final example that I'm gonna motivate is which is like, I'm, I've been trying to re progressively reduce the complexity of my examples. So we met from Uber, which is like a super long running, a lot of humans in the loop to YouTube, which is not so much humans in the loop. You upload it once and then everything else takes over from there. Now I just want to build one feature, which is a one-click buy button in React or in front end. It's actually super easy. It's a button. That's the literal simplest thing you can possibly do. You put an onclick handler. You're done. If you want to do a one-click buy, you do a setTimeout, and then say like, okay, if you want to cancel this within some window, with Amazon is 30 minutes, we can cancel it. But if you want to persist it, imagine if some person clicks, closes the browser and then changes their mind, opens the browser again, and it's gone. You're screwed. You don't have any other way to implement one-click [00:20:00] purchases. You need to implement timers on the backend to do this. I was watching this old talk from Joel Spolsky where he talks about the engineering for the one-click buy button. And I put it up on my YouTube because this is such an old talk. And I was afraid to link to the timestamp, but you can check it out as it's just a three minute video where he tells the story about how Amazon moved from shopping cart to one-click buy I mean they still have a shopping cart but it's that important because in online e-commerce actually even up to today the abandonment rate for shopping carts is 70%. So imagine if you implement this one feature, you improve your sales by I don't what's the inverse of 70%, three times. That's really amazing. So I think it's just fascinating and it's not just about Amazon. It's not about one click buy. It's about user experience. It's about making things easy and intuitive and that often involves turning synchronous things into asynchronous things and in persisting them so that they persist in the background. So I have a little demo here. I'm going to go really, really fast, but you can check out the code in temporalio/samples-node. There's the specific path this year but it's basically a Next.js demo where I have a Next.js folder here. This is going to be pretty standard for a lot of React developers. Hopefully you're familiar with Next.js, so you can learn it. It's got some pages and an API routes where I have serverless functions that call and send signals to my workflow functions. I have also a Temporal folder where I have written my workflows and activities. The activities are just a little logs obviously, cause they don't interact with any backends, but they could. And then the workflow coordinates the states in the background of all of these. So I can show you the code, but essentially I kick off a one-click buy with a purchase and then I set a timer and promise.race with a five second wait. So if I receive a cancel signal during that timer then that cancels if not, it goes through and the purchase is confirmed. Obviously I can. And what's fascinating about Temporal is that every single step is persisted in automatically saved. So in other words, I can sleep for 30 days. I can sleep for a year. I can sleep for five years and it doesn't matter because it's all persisted and wakes up automatically. So the compute the, this serverless function can be. The worker or a Temporal server itself can go down. You can just bring you back up again and it carries on as though nothing happened because of event sourcing. So, I'm gonna, I'm going to go ahead and run this. I think it's uh, demos I'm always stressed out about live demos. Okay. I mean, I did test it before the talk. It's just that whenever I'm streaming, like it adds an extra latency thing and that goes haywire. So, Let's see if I have this demo available. All right. So I also want to pull this out, which is the UI layer. These are the my test runs. But I have here at one-click purchase UI, and literally, I, you know, I, I want to implement this without a shopping cart, but I want to be able to cancel within some certain amount of time. So if I click buy, uh, it clicks, it handles it's. It sends a workflow. And that workflow starts in starts in the background and it's running, right. It's waiting for the timer to proceed. So I'm going to hit the timer, uh, and you can see that a timer started and time of ended, uh, within that five second window that I specified, obviously I should make it longer if I, if I really wanted to show this along the way. Um, so, uh, this, this is, this is as is purchased, um, and we can, uh, and now we've confirmed it. Um, but if I ever want to click buy, and then I can click the. That also fires off a different workflow, uh, where it sees that it receives the cancel signal from me. Uh, so, so I signaled it to cancel. And that's a very useful model as well. So this actually shows off a lot of the core principles of Temporal, which is you kick off a workflow, you can set durable timers, you can send it human signals and you can get out data as well with queries. There's a lot of interesting elements behind that, but that's the core demo that I wanted to show off. So maybe I'll write a YouTube example and then I'll go on to an Uber example and be a billionaire. [00:23:49] Talk Recap So ultimately I just want it to recap again, what we covered. We covered components, we covered architecture we covered time, and these are all the three elements I wanted to compare reacts and Temporal, and explain a little bit of how we think about doing the hard parts of making clones of very popular projects. Why is it so interesting? It's a little bit like the crabs story, you know. Obviously the founders of Temporal are not front end developers. They didn't even know react at all. [00:24:16] React and Temporal Full Comparison But they independently evolved a lot of the same principles and this that's, I haven't even gone into like the full comparison. So we talked a little bit about deterministic functions and local state and composition, but we haven't talked about normalization and how that compares dev tools. Testing is also super interesting thing as well as the central runtime. So there's a lot here, which I think. And fascinated by, and I'm obsessed by applying the lessons from React to things that are not React. [00:24:42] Conclusion: Enablement And I think overall, when I asked my CEO, like, what is the core message that we want to deliver is actually about enablements. Like we enable people to do things that they're not formally trained to do because we wrapped it up rapid all in a central runtime or central framework. So, uh, I always loved the Alfred north Whitehead quote that [00:25:00] civilization advances by extending the numberof things that we can do without thinking about it. So for me, my version of it is that B2B software advances by extending the number of jobs we can perform without formal training. And the message overall here is that Temporal lets backend developers or, just general full stack developers do distributed systems right? So that's it. I blasted through that. I only took 26 minutes. Really great for me, cause I was worried that it would take 50 and I'm happy to answer any questions you can hit me up on Twitter at Swyx. You can read my long form blog posts about why Temporal and then you can join our mailing list, YouTube or Slack. Thank you. Alright, thank you very much things. So I think that was a really, really nice. And you did, uh, went through that quite quickly. Uh, when I see the comments, people love the, like the most right there, because I could fail because I could fail. It's always like that. So, uh, yeah. Um, the nice thank you for the presentation. With this talk, I think it's actually the last talk of the event and I want to thanks everyone for joining us and thanks to everyone, thanks to all the speakers, of course, for being part of this event, uh, React New York 2021 and the sponsors. Um, I think this would be a good afternoon, I guess, or good night, depending on where we are in the world. Right. Have a good one. Everyone.

Economics and Open Source

Oxide and Friends

Play Episode Listen Later Oct 5, 2021 99:25

Oxide and Friends Twitter Space: October 4th, 2021Economics and Open SourceWe've been holding a Twitter Space weekly on Mondays at 5p for about an hour. Even though it's not (yet?) a feature of Twitter Spaces, we have been recording them all; here is the recording for our Twitter Space for October 4th, 2021.In addition to Bryan Cantrill and Adam Leventhal, speakers on October 4th included Edwin Peer, James Todd, Peter Corless, Matt Campbell, jasonbking, Simeon Miteff, Josh Clulow, Ian, Joe Thompson, Dan Cross, Tom Lyon, Tim Burnham, and vint serp. (Did we miss your name and/or get it wrong? Drop a PR!)Some of the topics we hit on, in the order that we hit them: Mark Jones Lorenzo (2017) Endless Loop: The History of the BASIC Programming Language bookJohn Kemeny wiki [@3:11](https://youtu.be/JDd8xGSP9DA?t=191) Tim's excellent tweet William Gibson wiki John Browne (1996) The Bug Count Also Rises short story [@5:38](https://youtu.be/JDd8xGSP9DA?t=338) Growing up with BASIC [@8:03](https://youtu.be/JDd8xGSP9DA?t=483) Braille 'n Speak PDA (intro video), BASIC programming TI-BASIC language [@10:39](https://youtu.be/JDd8xGSP9DA?t=639) Speaking program reading off system calls in real time snoop could output to /dev/audio [@13:39](https://youtu.be/JDd8xGSP9DA?t=819) Joel Spolsky (2002) Strategy Letter V blog Bryan's (2004) The Economics of Software blog Software “maintenance” [@20:02](https://youtu.be/JDd8xGSP9DA?t=1202) Cathedral and the Bazaar, wiki“Forkophilic” development model and the Alan Cox -ac Linux tree [@26:07](https://youtu.be/JDd8xGSP9DA?t=1567) Open source as something in the commercial best interest of a business SCO v IBM wiki Halloween documents wiki Steve Ballmer's “Linux is a cancer” quote in the Chicago Sun-Times OpenOffice.org wiki (open sourced from StarOffice) [@30:29](https://youtu.be/JDd8xGSP9DA?t=1829) Document editing as a service. Services and open source Richard Stallman on SaaS [@33:34](https://youtu.be/JDd8xGSP9DA?t=2014) The Joel Test link Joel's (2007) Strategy Letter VI blog “Everybody wants to be a platform” [@38:58](https://youtu.be/JDd8xGSP9DA?t=2338) Joel's take on Sun Making the pie larger. Porting NFS to rival platforms The Sun Network Filesystem: Design, Implementation and Experience has a section on porting experiences. Monetizing software - “Sun could never monetize software, only hardware” [@44:44](https://youtu.be/JDd8xGSP9DA?t=2684) Window toolkits, “cross platform”, write once run anywhere “Write once, debug everywhere” What's the directory separator on MVS? or Stratos VOS? [@51:40](https://youtu.be/JDd8xGSP9DA?t=3100) James' experience working on Tomcat Joel's (2002) Lord Palmerston on Programming blog Graphics toolkits, Electron/Web vs Native [@1:05:21](https://youtu.be/JDd8xGSP9DA?t=3921) “OpenSolaris downloads are potential buyers for the ZFS appliance” [@1:06:17](https://youtu.be/JDd8xGSP9DA?t=3977) Jason Hoffman “The Sun does not shine on me” Strategy cannot make up for poor execution Sun CEO Jonathan Schwartz didn't travel to meet customers Demoing to a hostile audience “Asteroid named Linux on a collision course” tweet [@1:13:20](https://youtu.be/JDd8xGSP9DA?t=4400) Open-core, AWS services, monetizing open source “People will pay for a service” Could Apple open source? [@1:18:43](https://youtu.be/JDd8xGSP9DA?t=4723) Packaged solutions; giving mom a linux box. Free software: free for whom? Support relationships. People want support [@1:22:05](https://youtu.be/JDd8xGSP9DA?t=4925) Why didn't Sun embrace Linux? ZFS on Linux, Ubuntu The Sourceware Operating System Proposal – Larry McVoy's open source SunOS 4 proposal. Sun bought Cobalt wiki [@1:25:33](https://youtu.be/JDd8xGSP9DA?t=5133) “The writing was on the wall for Sun..” x86 price-performance “Couldn't you buy like 100 x86 computers for that price?” RISC machine in-fighting, while Intel undercuts the market [@1:31:01](https://youtu.be/JDd8xGSP9DA?t=5461) Josh's work on frustrating hardware configuration [@1:33:25](https://youtu.be/JDd8xGSP9DA?t=5605) Peter's experience as a Sun customer Vertical scaling, but not so much horizontal scaling Clusters of cheap commodity hardware outperforming big multiway boxes Importance of open source for big internet companies Traders used Sun workstations, for fast trading [@1:38:39](https://youtu.be/JDd8xGSP9DA?t=5919) Oxide is bringing up their first server boards! If we got something wrong or missed something, please file a PR! Our next Twitter space will likely be on Monday at 5p Pacific Time; stay tuned to our Twitter feeds for details. We'd love to have you join us, as we always love to hear from new speakers!

pr speaking drop write open sun economics services basic window native saas intel document implementation open source cathedrals asteroids aws linux bazaar monetizing braille cobalt packaged matt campbell mvs oxide risc joe thompson zfs alan cox joel spolsky adam leventhal lord palmerston james todd opensolaris tom lyon sunos

Ep86 Founders at Work (with Jessica Livingston)

founders steve wozniak paul graham joel spolsky mitch kapor jessica livingston

Play Episode Listen Later Oct 5, 2021 43:19

In this talk Jessica Livingston - author of Founders at work - talks about the many lessons she learned from her interviews with the likes of Paul Graham, Steve Wozniak, Mitch Kapor and Joel Spolsky to name but a few. --- Send in a voice message: https://anchor.fm/business-of-software/message

Elegant Software [Joel Spolsky]

The Swyx Mixtape

Play Episode Listen Later Jul 21, 2021 7:52

Two anecdotes from StackOverflow founder Joel Spolsky, on how Google and Amazon wrote elegant software that balances simplicity and power.Audio: https://www.listennotes.com/podcasts/business-of/ep-70-simplicity-vs-value-in-YaRkM5T41IN/ (45mins in)Talk video: https://businessofsoftware.org/2009/01/joel-spolsky-at-business-of-software-2009-video/

amazon learning google business technology talk software elegant stack overflow joel spolsky

44bits 팟캐스트 121.log : 깃헙 장애, StackOverflow 매각, freenode 직원 이탈

44BITS 팟캐스트 - 클라우드, 개발, 가젯

Play Episode Listen Later Jul 8, 2021 62:45

44bits 팟캐스트 121번째 로그에서는 깃헙 장애, StackOverflow 매각, freenode 직원 이탈에 대해서 이야기를 나누었습니다. 참가자: @seapy, @raccoonyy, @outsideris, @ecleya 정기 후원 - 44bits podcast are creating 프로그래머들의 팟캐스트 녹음일 6월 17일, 공개일 7월 8일 쇼노트: https://stdout.fm/121/ 주제별 바로 듣기 00:00 후원 01:08 깃헙 장애 03:38 PolarDB for PostgreSQL 16:18 오픈소스 Email Alias - SimpleLogin 23:24 StackOverflow 매각 39:13 네이버 소프트웨어 서비스 종료 41:55 freenode 직원 이탈 쇼노트 깃헙 장애 GitHub Status - Incident with GitHub Actions, API Requests, Git Operations, Issues, GitHub Packages, GitHub Pages, Pull Requests, and Webhooks PolarDB for PostgreSQL PolarDB for PostgreSQL Ant Design - The world's second most popular React UI framework Deno - A secure runtime for JavaScript and TypeScript - DenoLand TOAST UI :: Make Your Web Delicious! 오픈소스 Email Alias - SimpleLogin SimpleLogin | Open-source email alias solution StackOverflow 매각 Stack Overflow Sold to Tech Giant Prosus for $1.8 Billion - WSJ Prosus Joel on Software Coding Horror Jeff Atwood - Wikipedia Joel Spolsky - Wikipedia 네이버 소프트웨어 서비스 종료 네이버 소프트웨어 서비스 종료 안내 freenode 직원 이탈 Freenode IRC staff resign en masse after takeover by Korea's “crown prince” | Ars Technica Libera Chat | A next-generation IRC network for FOSS projects collaboration! Discord | Your Place to Talk and Hang Out Welcome to your new HQ | Slack Redmine Apache Subversion The Trac Project Google Wave - Wikipedia

talk software korea javascript hangout foss irc stack overflow ars technica postgresql github actions pull requests google wave webhooks jeff atwood joel spolsky github pages freenode coding horror apache subversion

Ep 70 Simplicity vs Value in Software Development (with Joel Spolsky)

simplicity software development bos joel spolsky

Play Episode Listen Later Jun 8, 2021 53:01

Fly in the face of what is often perceived as wise strategy and hear how building new features does add value to your product with Stack Overflow Founder Joel Spolsky. For more great talks, visit businessofsoftware.org and join thousands of other smart folk enjoying the benefits of the BoS community. --- Send in a voice message: https://anchor.fm/business-of-software/message

A Look into Modern Leaky Abstractions - Postgres, MySQL, HTTP/2, TCP, ORMs GraphQL, N+1, Axios, git

IGeometry

Play Episode Listen Later Apr 17, 2021 37:49

Leaky abstractions occur when the consumer of the abstraction started asking questions about certain behavior which ends up with the need to understand the details behind the abstraction. Joel Spolsky coined this term and in this video I’d like to discuss this concept and provide few examples of my own experience towards leaky abstractions. Let us get on with the show. 6:00 Postgres Dead Tuples 7:25 MySQL Clustering 9:23 Axios HTTP Library 11:30 ORMs (N+1) 13:30 Beyond Abstractions 15:30 TCP 19:30 HTTP/2 27:00 Microservices 28:40 Index Only Scans Postgres 33:35 git 34:50 Summary --- Send in a voice message: https://anchor.fm/hnasr/message

modern axios leaky abstraction mysql graphql postgres orms joel spolsky

How to Convince Management to Adopt Agile

The Agile Embedded Podcast

Play Episode Listen Later Apr 14, 2021 39:31

You can find Jeff at jeffgable.com.You can find Luca at luca.engineer.Joel Spolsky's post "Getting Things Done when You're Only a Grunt"

management adopt agile convince getting things done medical devices grunt embedded systems joel spolsky

Welcome to 2021 with special guest Joel Spolsky

Play Episode Listen Later Jan 1, 2021 37:24

You can find the first episode of the SO podcast here. It was conducted over Asterix, open source telephony software that allowed for fancy operations like voice messaging and recording calls! What would social software look like if we designed them to remove commerce and popularity? Are services like Mightybell an interesting example of where we might be headed?If you want to build a model of something - say traffic patterns in your town or a hypothetical zombie invasion - you should check out a new project Joel is involved in, Hash.ai.

hash asterix joel spolsky mightybell

Welcome to 2021 with special guest Joel Spolsky

web albert einstein sito cura siamo nessuno fiducia comblog circolo manutenzione dettaglio joel spolsky

Play Episode Listen Later Jan 1, 2021 37:24

hash asterix joel spolsky mightybell

Hot New Hash

HOT NEW TECH

Play Episode Listen Later Sep 8, 2020 31:18

Could hash's data simulator be the next trello, glitch or stack overflow? It has Joel Spolsky's magic dust on it and a juicy mission statement so we checked it out! Using Javascript we attempted to create Netflix‘s "Indian Matchmaking" world in this data ai simulation engine. Check out the latest episode for our review of hash.ai!Links: Get started with Hash: https://hash.ai/Joel on hiring engineers: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/Indian Matchmaking Trailer: https://www.youtube.com/watch?v=aZS2KbLAy5YSupport the show (https://www.patreon.com/hotnewtech)

netflix hash hot new indian matchmaking joel spolsky using javascript

The Founders' List: Joel Spolsky (Co-Founder of Trello & Stack Overflow) on "Strategy Letter I: Ben and Jerry’s vs. Amazon"

The NFX Podcast

Play Episode Listen Later Aug 24, 2020 14:48

This is The Founders' List - audio versions of essays from technology’s most important leaders, selected by the founder community. This essay was written and published on May 12, 2000 by Joel Spolsky, Co-Founder of Trello & Stack Overflow. Read the full article here: https://www.joelonsoftware.com/2000/05/12/strategy-letter-i-ben-and-jerrys-vs-amazon/

ceo amazon founders success strategy advice tech co founders entrepreneurship startups mentor letter companies trello stack overflow nfx joel spolsky james currier spolsky

E81 - Michael Pryor, Trello

Open the Pod Bay Doors

Play Episode Listen Later Apr 21, 2020 79:59

Today we speak with Michael Pryor, co-founder, CEO and current Head of Product for Trello at Atlassian. Trello was acquired by Atlassian in 2017 for $425M and stands as Atlassian's largest-ever acquisition. Trello is one of many products developed by Fog Creek Software, a company Michael co-founded with Joel Spolsky back in 2000. Michael's co-founder pitched Trello at TechCrunch Disrupt in 2007 with the lofty goal of attracting 100 million users. Now, 13 years later, over 50 million people are signed up for Trello and that goal doesn't seem so lofty anymore.In addition to the birth and growth of Trello, this episode also focuses on how to effectively work remotely. Two thirds of Trello's workforce is remote, so Michael shares his tested strategies for how to build, manage, and grow a remote workforce.

ceo founders head business interview startups product saas remote work trello atlassian remote working techcrunch disrupt joel spolsky michael pryor fog creek software

004 Il circolo del risentimento

AA..A.I. Cercasi

Play Episode Listen Later Mar 25, 2020 20:45

E' sempre necessario rifare daccapo un lavoro? Siamo sicuri che chi l'ha progettato dall'inizio abbia fatto degli errori irreparabili tanto da non poterlo recuperare? Nell'era del consumismo più sfrenato, quanto è sottostimata la "manutenzione"? Ed è giusto che sia così? E, infine, siamo sicuri che al posto del precedente designer avremmo fatto meglio?INSTAGRAM: CercasiaiEMAIL: aaaicercasi @ gmail.comBLOG: aaaicercasi.wordpress.com SPONSOR: myfoglio.com A proposito di Software Joel Spolskyhttps://www.amazon.it/proposito-software-Joel-Spolsky/dp/8861140122"Alla gente sembra sempre che gli altri non facciano nulla come si dovrebbe, che gli altri facciano tutto sbagliato. Invariabilmente ognuno pensa che lui potrebbe fare meglio. Nessuno comprende né vuol comprendere che ciò che viene fatto attualmente in un certo modo — e soprattutto ciò che è stato già fatto — non poteva essere fatto altrimenti." Gurdjieff"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi." attribuita ad Albert Einstein

How to Find Your Next Stop

Play Episode Listen Later Mar 3, 2020 25:29

Echeruo's new venture is called Love and Magic, a startup studio that helps companies of all sizes maximize their ability to innovate. For anyone that has an idea they have been hoping to turn into a startup, Echeruo and his collaborators just introduced the Startup School of Alchemy. It's being taught at WeWork and Princeton University. It offers a six-week curriculum designed to help aspiring entrepreneurs find product-market fit.Apply with the code "stackoverflow" and you get $1000 off the course, a 40% discount.Echeruo says his time working in finance and with Microsoft Excel was what gave him the ability to think of how data from maps could be optimized by an algorithm and built into a useful mobile app. For those who don't know, our co-founder and Chairmam, Joel Spolsky, was part of the team at Microsoft that built Excel. Here is legendary 2015 talk, You Suck at Excel, where he organizes a spreadsheet to keep track of what he pays his Pokemon, ahem,I mean, uh, employees. You can take a deeper dive into the backstory of how Chinedu built HopStop below, related in his own words.I've always had difficulty with directions. When I grew up in Nigeria, I remember getting lost in my own house. It wasn’t like it was a mansion, it was a four-bedroom house. So you can imagine how I felt when I got to NYC and had to get around with the subway and bus system! I remember walking up once to one of those blown up maps in the subway station. My nose was a feet away from the dust laden map. The subway lines looked like tangled noodles. Complexity galore! New Yorkers used to walk around with these pocket guides—Hagstrom maps. I was going on a date in the Lower East Side. It doesn’t have the grid like the rest of the city. I got lost and was very late getting to the bar.I can't remember how, the date went but I remember what I did first thing next morning. I walked over to the subway station, grabbed a subway MAP and laid it on the floor and tried to figure it out. There’s driving directions. But there weren’t subway directions. So I was solving my own problems. I was looking for the complete directions—leave your house, turn left, go into this particular entrance, get on this train, get off at this station, use this exit. Because I was, in a lot of ways, the ultimate user, we ended up building a product that solved the complete problem—get me from where I am now to where I need to be. I was non-technical, I worked for a hedge fund. I may have been thinking algorithmically, I knew that this was computationally possible. But I didn’t know how to make it a reality. In conceiving the problem, I threw all the data into spreadsheets. I interned at this company when I was in college, where I learned about spreadsheets. I found the work very tedious, but I learned how to think about data, to think in tables. It allowed me to conceptualize complexity. To conceptualize the first subway data as a spreadsheet, I started by staring at the subway map laid on the wood floor of my apartment. The most obvious features were colors, lines, and stops. So those are the tables I typed into Excel first. Then I realized the lines also represented two train directions so I redid the spreadsheet. Then I realized the stops served multiple subway lines, so I redid the spreadsheet. Then I realized some of the stops would only be active during certain periods, so I redid the spreadsheet. We kept on learning and adjusting. It took us a long time before we had a data model that robustly described NYC's subway system. We even figured out how to automatically account for the frequent weekend NYC subway diversions.To build the first version of the app, I went to eLance, described to these computer scientists the data set in Excel, routes, stops, exits, entrances, and I sent it in. This developer in Siberia, Russia, emailed me, came up with a solution. But he turned out to be a complete genius, he built the core of the first version of Hopstop. Here I was, a Nigerian, sitting in my apartment using messenger, email, on a laptop. And I never met Alex for four years. We built Hopstop over four years without ever meeting each other.We ran very lean. Alex did all the coding. I did the subway data and user experience. I'd have to ride to different subway stations to note each subway entrance and exit, etc. When we added the bus system, Rajeev and his data team in India helped input the bus stops and schedules. And four years later, we were purchased by Apple, so quite the ride.

How to Find Your Next Stop

Play Episode Listen Later Mar 3, 2020 25:29

Echeruo's new venture is called Love and Magic, a startup studio that helps companies of all sizes maximize their ability to innovate. For anyone that has an idea they have been hoping to turn into a startup, Echeruo and his collaborators just introduced the Startup School of Alchemy. It's being taught at WeWork and Princeton University. It offers a six-week curriculum designed to help aspiring entrepreneurs find product-market fit.Apply with the code "stackoverflow" and you get $1000 off the course, a 40% discount.Echeruo says his time working in finance and with Microsoft Excel was what gave him the ability to think of how data from maps could be optimized by an algorithm and built into a useful mobile app. For those who don't know, our co-founder and Chairmam, Joel Spolsky, was part of the team at Microsoft that built Excel. Here is legendary 2015 talk, You Suck at Excel, where he organizes a spreadsheet to keep track of what he pays his Pokemon, ahem,I mean, uh, employees. You can take a deeper dive into the backstory of how Chinedu built HopStop below, related in his own words.I've always had difficulty with directions. When I grew up in Nigeria, I remember getting lost in my own house. It wasn't like it was a mansion, it was a four-bedroom house. So you can imagine how I felt when I got to NYC and had to get around with the subway and bus system! I remember walking up once to one of those blown up maps in the subway station. My nose was a feet away from the dust laden map. The subway lines looked like tangled noodles. Complexity galore! New Yorkers used to walk around with these pocket guides—Hagstrom maps. I was going on a date in the Lower East Side. It doesn't have the grid like the rest of the city. I got lost and was very late getting to the bar.I can't remember how, the date went but I remember what I did first thing next morning. I walked over to the subway station, grabbed a subway MAP and laid it on the floor and tried to figure it out. There's driving directions. But there weren't subway directions. So I was solving my own problems. I was looking for the complete directions—leave your house, turn left, go into this particular entrance, get on this train, get off at this station, use this exit. Because I was, in a lot of ways, the ultimate user, we ended up building a product that solved the complete problem—get me from where I am now to where I need to be. I was non-technical, I worked for a hedge fund. I may have been thinking algorithmically, I knew that this was computationally possible. But I didn't know how to make it a reality. In conceiving the problem, I threw all the data into spreadsheets. I interned at this company when I was in college, where I learned about spreadsheets. I found the work very tedious, but I learned how to think about data, to think in tables. It allowed me to conceptualize complexity. To conceptualize the first subway data as a spreadsheet, I started by staring at the subway map laid on the wood floor of my apartment. The most obvious features were colors, lines, and stops. So those are the tables I typed into Excel first. Then I realized the lines also represented two train directions so I redid the spreadsheet. Then I realized the stops served multiple subway lines, so I redid the spreadsheet. Then I realized some of the stops would only be active during certain periods, so I redid the spreadsheet. We kept on learning and adjusting. It took us a long time before we had a data model that robustly described NYC's subway system. We even figured out how to automatically account for the frequent weekend NYC subway diversions.To build the first version of the app, I went to eLance, described to these computer scientists the data set in Excel, routes, stops, exits, entrances, and I sent it in. This developer in Siberia, Russia, emailed me, came up with a solution. But he turned out to be a complete genius, he built the core of the first version of Hopstop. Here I was, a Nigerian, sitting in my apartment using messenger, email, on a laptop. And I never met Alex for four years. We built Hopstop over four years without ever meeting each other.We ran very lean. Alex did all the coding. I did the subway data and user experience. I'd have to ride to different subway stations to note each subway entrance and exit, etc. When we added the bus system, Rajeev and his data team in India helped input the bus stops and schedules. And four years later, we were purchased by Apple, so quite the ride.

A Dash of Anil, a Pinch of Glimmer, a splash of Glitch

Play Episode Listen Later Feb 25, 2020 29:39

Glitch, a platform that makes it easy for anyone to create or remix a web app, has seen over five million apps created by users. You can read more about how it works here. If you want to learn a little about how it works with Docker, check out this piece here.If you want to know more about the shared history of Stack and Glitch, you can read up on it here. TLDR; Glitch was born out of Fog Creek software and counts Joel Spolsky and Michael Pryor as founders. Glimmer is a new web magazine from the folks at Glitch. It focuses on creators and makers, with a special emphasis on unearthing the human stories of people building today's software.While you're here, don't forget to take 15-20 minutes and share your opinions in our 2020 Developer Survey. Whether Stack Overflow helped you during your journey as a programmer or not, we want to hear from everyone who codes. Some fun background for younger listeners: Geocities - a popular platform for building and hosting a personal website and linking it with others that share similar themes. BetaBeat - a website launched by The NY Observer that covered the SIlicon Alley tech scene. It was how Ben first met Anil, Joel, and many others. HerokuDockerIf you have comments, questions, or suggestions, please send us an email at podcast@stackoverflow.comToday’s episode is brought to you by Refinitiv. Unlock new possibilities with consistent, high-value market data from Refinitiv. Try the Refinitiv Eikon Data API for the largest breadth and depth of data and community tools with native Python support. Check out refinitiv.com/stackpodcast to try the Eikon Data API today. Refinitiv. Data is just the beginning.

data unlock stack splash python glitch pinch docker anil glimmer tldr refinitiv silicon alley joel spolsky michael pryor ny observer fog creek

A Dash of Anil, a Pinch of Glimmer, a splash of Glitch

Dentro do Ringue - Startups e Tecnologia

Play Episode Listen Later Feb 25, 2020 29:39

Glitch, a platform that makes it easy for anyone to create or remix a web app, has seen over five million apps created by users. You can read more about how it works here. If you want to learn a little about how it works with Docker, check out this piece here.If you want to know more about the shared history of Stack and Glitch, you can read up on it here. TLDR; Glitch was born out of Fog Creek software and counts Joel Spolsky and Michael Pryor as founders. Glimmer is a new web magazine from the folks at Glitch. It focuses on creators and makers, with a special emphasis on unearthing the human stories of people building today's software.While you're here, don't forget to take 15-20 minutes and share your opinions in our 2020 Developer Survey. Whether Stack Overflow helped you during your journey as a programmer or not, we want to hear from everyone who codes. Some fun background for younger listeners: Geocities - a popular platform for building and hosting a personal website and linking it with others that share similar themes. BetaBeat - a website launched by The NY Observer that covered the SIlicon Alley tech scene. It was how Ben first met Anil, Joel, and many others. HerokuDockerIf you have comments, questions, or suggestions, please send us an email at podcast@stackoverflow.comToday's episode is brought to you by Refinitiv. Unlock new possibilities with consistent, high-value market data from Refinitiv. Try the Refinitiv Eikon Data API for the largest breadth and depth of data and community tools with native Python support. Check out refinitiv.com/stackpodcast to try the Eikon Data API today. Refinitiv. Data is just the beginning.

data unlock stack splash python glitch pinch docker anil glimmer tldr refinitiv silicon alley joel spolsky michael pryor ny observer fog creek

211: 4 weeks, 3 days (Repeat)

Embedded

Play Episode Listen Later Jan 30, 2020 79:47

Dennis Jackson spoke with us about making the career shift from software to embedded. Dennis buys James Grenning’s Test Driven Development in Embedded C for his new hires and often recommends Elecia’s Making Embedded Systems. His tip that everyone should know was “Learn make!” and he has a reference for that: Why Use Make. He suggested Joel Spolsky’s reading lists from Joel On Software, even the ones that don’t obviously apply. Additional suggested-reading articles: 30 Pitfalls for Real Time Systems (part 1 and part 2) Rules for defensive C programming Why are you still using C What every computer scientist should know about floating point arithmetic The Power of Ten -- 10 Rules for Writing Safety Critical Code In his previous appearance on Embedded (#94: Don’t Be Clever), we talked about code complexity and measuring cyclomatic complexity. At that time he wanted a tool to monitor the code’s status. He has since found one: pmccabe.

power pitfalls embedded test driven development joel spolsky dennis jackson elecia

#8 Comunidades tech – Inclusão a favor do conhecimento

Play Episode Listen Later Jan 22, 2020 34:28

O principal objetivo desse cast é ilustrar o porquê das comunidades techs serem importantes para o desenvolvimento do país e do ecossistema de tecnologia. O Dentro do Ringue é um podcast da Vindi (vindi.com.br) sobre cultura, startups e tecnologia. #8 Comunidades tech - Inclusão a favor do conhecimento Host: Rodrigo Dantas, CEO da Vindi LinkedIn; Instagram; Twitter. Fábio Akita - Criador da RubyConf, uma das maiores conferências de tecnologia da América Latina. Ele é Co-Fundador da Codeminer, empresa de desenvolvimento de software. Linkedin; Evento - The Conf. Vitor Kusiaki - Vitor é engenheiro de software da Vindi. Formado pela Universidade Federal de São Carlos, ele trabalhou na Trackmob e na Codeminer. LinkedIn; Thais Kusuki - Thais é engenheira de software da Vindi. Formada pela Universidade Mackenzie, ela trabalhou na Campus Code e na BSP. LinkedIn; Mas, quem é o AKita? Lançou em 2006, um blog que ficou bem famoso, o Akita on Rails, que discute tecnologia, produto e linguagem de programação. Em 2011, criou a CodeMiner, uma consultoria de desenvolvimento de software especialista em Ruby on Rails. Fundou um dos eventos de maior referência no mercado, o RubyConf e, posteriormente, o TheConf. Ele trabalha como programador desde o começo dos anos 90 e passou por todas as principais tecnologias do mercado nesse período. Democratização do conhecimento Desenvolvimento e criação de software é algo muito democrático nos dias de hoje. Mesmo que muito complicado em alguns casos, a barreira de se tornar um engenheiro de software, transcendeu os muros das universidades. Hoje, os programadores aprendem a “codar” com diferentes caminhos: desmontando videogames (como era no passado), criando sites, sistemas, automatizando tarefas, lendo livros, fazendo cursos on-line e...participando de comunidades techs - espalhadas pelo país. O Stack Overflow existe exatamente por essa necessidade em compartilhar conhecimento através de comunidades. Criado por Joel Spolsky e Jeff Atwood (ambos desenvolvedores) em 2008, eles perceberam que naquela época era muito complicado encontrar um site de perguntas e respostas que fosse gratuito e de qualidade para buscar informações específicas dentro da área de desenvolvimento de software: “Se você tiver com muita sorte, na quarta ou quinta página de resultados de uma busca, você encontrará uma discussão de sete páginas com centenas de respostas, das quais 25% são spam”, disse Joel em um de seus posts famosos na plataforma. Vai bem mais além do que só para programadores Com o advento de novas linguagens, tecnologias novas e comunidades se espalhando pelo mundo, o Stack Overflow cumpre com um papel fundamental para qualquer pessoa que está iniciando a carreira em tecnologia: ela democratiza a informação. Na época de fundação do Stack Overflow, já existiam diversos fóruns famosos. Um exemplo disso era o Yahoo Respostas, que para a galera de tecnologia, não cumpria com a promessa de subir um pouco o nível das respostas de iniciantes e pessoas com dúvidas específicas de certas linguagens. Na maioria das comunidades techs, as perguntas não tinham uma validação técnica. Foi exatamente aí que a empresa surgiu e resolveu um grande problema: perguntas e respostas validadas pela própria comunidade. O grande sucesso da plataforma é que além do fórum, eles conseguiram criar uma grande comunidade dentro dela para votar nas melhores perguntas e respostas, criando um ambiente gamificado de conteúdo relevante dentro da própria rede. Com mais de 27 milhões de perguntas e mais de 27 milhões de respostas, o site é um dos mais acessados do mundo. Esse sucesso tem a ver com a comunidade de engenheiros que se formou em volta. Perguntas de tempos atrás podem ser atualizadas por novas linguagens, problemas novos e atuais, o que faz do Stack Overflow ser uma grande biblioteca de tecnologia: aberta, mutável, colaborativa e poderosa.

380 Bumpers 62

Reversim Podcast

Play Episode Listen Later Nov 6, 2019

פרק מספר 62 של באמפרס (380! למניין רברס עם פלטפורמה) - רן, אלון, ודותן בבוקר (חורפי ולא חם סוף-סוף) של סוף אוקטובר עם סקירה של טכנולוגיות ודברים מעניינים מהזמן האחרון.רן - סטנדרט חדש הולך ומתהווה - GQLסטנדרט שאילתות ל- Databases ראשון מאז SQL שנקבע אי שם בשנות ה- 70-80 . . .המטרה היא להסדיר את נושא השאילתות ב Graph Databases (דוגמת Neo4j שמניעים אותו, אבל יש גם אחרים) - וזה כרגע בתהליך של קבלה לועדת הסטנדטים ANSIאפשר לעקב אחרי התהליך והשלביםיש כל מיני הצעות ועדיין לא הוחלט באופן סופי - בעולם ה - Databases יש לא מעט שפות שבהן ניתן לתשאל Graph databases, ובסופו של דבר המטרה היא להתקבע על אחת, שתיהיה סטנדרטית בדומה ל-SQL.אזהרה (!) - חשוב לשים לב ולא להתבלבל בין GQL לבין GraphQL . . . . אלו שני דברים שונים:מצד אחד -GraphQL זו שפת שאילתות או בעצם קצת יותר כמו פרוטוקול בסגנון REST - משתמשים מעל HTTP אבל זו לא השפה שבא “מדברים” עם ה - Database.לעומת זאת - GQL, קצת כמו SQL, הוא הסטנדרט (המיועד) - סטנדרט טקסטואלי שבו ניתן לכתוב שאילתות טקסט ל Graph Databases.הרבה מאוד זמן לא ראינו תנועה באיזור הזה, ומעניין שעכשיו יש.מי מבין מאזינינו שהוא במקרה גם בעלים של טסלה (אפי?!) ודאי מאוד התרגש לשמוע שהגרסא החדשה של התוכנה - 10.0 - יצאה.גם למי שאין לו במקרה (רן, למשל - מסתבר שזה פחות הולך בישראל בינתיים) - מעניין לראות שהגרסא נראית פחות או יותר כמו עדכון של IOS או Android: אם מסתכלים על רשימת הפיצ’רים, קשה לנחש שמדובר ברכב . . .הרבה דברים שקשורים לפנאי ולבידור - חיבורים ל - YouTube ול - Spotify, קריוקי וכאלהכמעט שלא תראו פיצ’רים שקשורים למנוע או לחלקים אחרים של, ובכן - רכב…הרכב נראה כפלטפורמת בידור, לפחות לפי הגרסא הזו. מעניין - הופך למערכת הפעלה לפנאי ופחות מערכת הפעלה לרכב.אלון - מישהו אמר (Twitter …) שלא האמין שיגיע לתקופה שבה עדכון של רכב יותר מרגש מעדכון של טלפון . . . מגניב.מתי העדכון הבא של אאודי? אה.ספריה בשם chart.xkcd - מעיין גרפים ב - JavaScript או HTML וכו’ שרצים בתוך הדפדפן - בסגנון xkcd:סדרת קריקטורות גיקיות פופולארית, בעיקר סביב מחשבים וטכנולוגיה, בעיצוב שדומה לעיפרון או עט גס, בשחור לבן “פשטני”.הספריה הזו מייצרת גרפים ותרשמים בסגנון - “כאילו שורטטו בעיפרון או טוש על נייר”.יש גם צבעים - לא רק שחור-לבן כמו ב”מקורי”.אחד המגניבים . . . יש טרנד כזה של מצגות שנראות כאילו עכשיו שרבטו אותן? אז כזה - נראה טוב וקריא מאוד.הפינה האמנותית - Repo ב - GitHub בשם The art of command lineמעניין סקירה של כלים (Unix, Linux) מאוד שימושיים , החל מאיך משתמשים ב - Bash (ה - Shell עצמו) והלאה.למשל - מה קורה שעושים Alt+B ואז Alt+F ? - מסתבר שזה מביא אתכם לתחילת השורה - במקום ללכת “אחורה בהיסטוריה” בשיטת “חץ למעלה-למעלה-למעלה” ואז לנסות להגיע למשהו באמצע, Alt+B ואז Alt+F מאפשר לעבור מילה אחרי מילה.אפשר גם להשתמש ב “VI Mode” בתוך ה - CLI עצמו - לעבור ולהשתמש בקיצורי הדרך של VI.אפשר גם לערוך את ה - Command Line שלכם בתוך Editor ועוד כל מיני פטנטים שאולי לא הכרתם.למי ש”חי בתוך ה - Command Line” (גרסא מאוד מוזרה של Jumanji?) - מומלץ.לא מאוד ארוך, חלק סביר שאתם מכירים - רן לא הכיר הכל. שווה לנסות.בלוג-פוסט מעניין ומעורר השראה - Logs were our lifeblood. Now they're our liabilityיש הרבה מאוד סוגים של לוגים - החל מלוגים “אופרטיביים” (Operational) בסגנון “נגמר לי המקום בדיסק” או exception כזה או אחר ועד לוגים “אפליקטיביים” (Application) - שהבלוג מגדיר כ - Events ואליהם הוא מתייחס.דברים כמו Analytics למיניהם ש Google ו - Facebook אוהבים (לכאורה) לאסוף (לכאורה!) על פעולות של משתמשים.אומרים ש”דאטה זה הזהב החדש” וזה כנראה נכון בהרבה מובנים - ככל שתאספו יותר מידע על המשתמשים שלכם כך תוכלו לההפיק יותר תובנות, אבל . . .עם הגידול ברגולציות השונות, מתברר שזה לא כל כך פשוט לתחזק את כל הלוגים האלה - אם זו רגולציה באירופה וארה”ב וסין ועוד - מגלים שמצד אחד הדאטה שווה זהב, ומצד שני - “יכולים לתבוע לכם את התחת” אם לא תשמרו על הזהב הזה כמו שצריך ולא תדעו למחוק אותו ולעשות לו סגרגציה (Segregation) כמו שצריך, אז אם חס וחלילה מתרחשת דליפת מידע . . .הבלוג טוען שאם פעם היינו רק רוצים לאסוף כמה שיותר מידע, היום - ובטח שבעתיד - צריך לעשות את זה במשנה זהירות.הצפי הוא לפיתוח טכניקות שבהן נוכל אולי לשמור את ה -Essence של המידע - מבלי לשמור את ה - Data עצמו.ציטוט ממישהו שנראה שמגיע מ - Facebook, שאומר ש”את הקהל שלנו אני יכול לייצג באמצעות חמישה משתמשים בלבד” - 5 Archetypes של משתמשים שמהם אפשר ללמוד את כל מה שצריך, ולא צריך את כל המיליארד או 2 מיליארד או כמה שזה לא יהיה.למעשה, זה מצביע על טרנד ב - Data Science שיודע לקחת הרבה מאוד Data, להוציא ממנו רק את הייצוגים המעניינים - “ולזרוק” את כל השאר.ה-MP3 של כל שאר הדאטה?(אלון) מעניין מאוד לחברות בתחילת הדרך - חברות ענק כבר מאוד מתעניינות ב - Long Tail, ואם תבוא ותגיד להם “הנה רק 5 ייצוגים” הם לא יגיבו יפה.יכול להיות - אבל מצד שני הרגולציות הולכות וגדלות, ולא נראה שזה הולך להיעלם - באיזשהו מקום הם יהיו חייבים. לחברות בתחילת הדרך זה אולי יהיה “יותר קל” (לוותר), אבל דווקא לחברות הגדולות יש את ה Liability היותר גדול ואולי לא תיהיה להן ברירה.את מי כבר תבעו - ?Google? Facebook - שתיהן?אם מסתכלים על GDPR - ההגבלה היא על מה שהוא Tractable למשתמש ספציפי - אם שומרים בצורה אנונימית אז אין עם זה שום בעיה.ברגע שלוקחים רק Samples אז מראש יוצאים מבעיות רגולציה - אבל העניין הוא שחברות כאלו כן רוצות את כל ה - Data ... זה נחמד לדברים מסויימים, אבל לא למשל עבור פרסונליזציה…הבלוג בא להצביע על בעיה - ולא טוען שיש לו פתרון להכל. הפתרונות שכן מוצעים הם אגרגציה ואנונימיזציה (Aggregation, Anonymization), שזה מה שעושים למשל ב - Google.הבעיה קיימת, ואי אפשר להתעלם ממנה - אם פעם (ועדיין) לוגים היו הזהב החדש, היום אנחנו מבינים שלזהב הזה יש מחיר ויש ריבית, וזה בטח לא בא בחינם.צריך לחשוב על איך לא להחזיק מידע מיותר - לא משיקולי Storage אלא משיקולי Liability - ואיפה שאפשר לעשות אגרגציה ואנונימיזציה או דברים אחרים.זה בהחלט מציג אתגרים - גם ליישום יעיל ונכון וגם מבחינת פגיעה בפיצ’רים עתידיים - אם בעוד שנה תרצה לעשות פרסונליזציה - תיהיה לך בעיה.האמירה שלוגים הולכים והופכים ל Liability נראית נכונה, ונראה שתיהיה אפילו יותר נכונה עם הזמן.עד כאן סוגיות חוקיות להיום? ספויילר - כנראה שלא . . .תראו מי חוזר - !The Stack Overflow Podcast is Backלמי שזוכר (רומז שאנחנו זקנים?), הפודקאסט היה קיים משך שנים רבות ולאחרונה נכנס לקצת תרדמתהפודקאסט עצמו יותר ותיק מרברסים (!), בן למעלה מ-12 שניםרן עוד זוכר את עצמו מאזין ל Joel Spolsky וחושב שאולי כדאי שיהיה גם אחד כזה בעברית... יצא בסדר בסך הכל

The Law of Leaky Abstractions - Joel Spolsky - November 2002

Tech Aloud

Play Episode Listen Later Sep 21, 2019 14:26

Source: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ This post is 17 years old, but still totally relevant today in what it teaches us - that while we construct new software architectures on top of older ones, things are still hard - harder, even - when problems occur. And there's a great line in this article that is worth quoting here: "... abstractions save us time working, but they don’t save us time learning".

leaky abstraction joel spolsky

371: Absurd Abstractions

Coder Radio

Play Episode Listen Later Aug 19, 2019 39:22

It’s a Coder Radio special all about abstraction. What it is, why we need it, and what to do when it leaks. Plus your feedback, Mike’s next language challenge, and a functional ruby pick.

api open source inte absurd rails s3 abstraction ruby on rails knuth functional programming minio joel spolsky donald knuth coder radio

17. Scapegoats For A Rewrite

Technology Leadership Podcast Review

Play Episode Listen Later Aug 5, 2019 19:47

Dave Thomas and Andy Hunt on The Changelog, Stacey Barr on Coaching For Leaders, Nic Sementa on Drunken PM, Christopher Avery on Agile Uprising, and Steve Poling on Maintainable. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting August 5, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. DAVE THOMAS AND ANDY HUNT ON THE CHANGELOG The Changelog podcast featured Dave Thomas and Andy Hunt with host Adam Stacoviak. Dave and Andy were on the show to talk about the 20th anniversary of the book The Pragmatic Programmer and its new edition. Adam asked how the book remains relevant given the short half-lives of most technology books. Dave clarified that the book is not really a technology book but a book about people and people haven’t changed that much. The biggest updates to the book were not due to changes in technology but due to changes in the authors’ experience and their discovery of better ways of explaining things. One example was the DRY principle that has come to mean, “Don’t cut and paste,” while its original meaning was not about code at all but had to do with knowledge. Andy was surprised upon revising the book to realize how much the world has changed in twenty years. Twenty years ago, he says, AOL was carpet-bombing people with CDs, very few of us had to worry about security as it was a struggle enough to get your code to work at all, and unit testing wasn’t commonly practiced. Andy said that they originally had intended to write a little whitepaper describing what they observed going from client to client and seeing the same classes of mistakes over and over. They came up with a set of stories, anecdotes, and metaphors to explain the concepts like “tracer bullet”. They intended to hand out this little whitepaper at clients but it just kept growing until it was a book. Adam asked what has changed in the last twenty years. Andy noticed on reviewing that he found the book more object-oriented than he thought it was. Dave says that people haven’t changed, but people’s sensibilities have: with the pervasive impact of computer technology on our lives, the responsibility being put on developers to behave ethically has increased dramatically. In his experience, twenty years ago, you wrote boring code that did some business function. Today, we’re writing code that can change people’s lives. We need to think a lot harder about the impact of the code we write. Adam asked how we can institutionalize the passing on of knowledge by those who came before. Andy wishes that academia had a greater interest in teaching the history of computing. Dave says this doesn’t need to be a separate class. If you want to become an author, you do a lot of reading. Instead of reading books, he says, developers should be reading code and reading a great variety of code. Teaching, he says, should involve learning how people did things in the past, reading their code, and then discussing why they made the choices they did. He gave the example of the C increment and decrement operators. In Bell Labs, the machines had seven addressing modes and two of them were pre- and post- increment address dereference. So the C operators mapped directly to the hardware. Another example is the famous paper, “GOTO Considered Harmful.” Entire languages have been written without GOTO based on the title of that paper. The original letter that the paper came from did not even have this title. The letter was about program-proving and the editors gave a “sexier” title. We carry around these things we have received based on headlines like “GOTO Considered Harmful” and we don’t even know why we do it. Adam asked how the next generation is going to gain a reverence for computing history. Andy suggested that mentors could instill this. Dave pointed out that we now live in an age when you can experience the history first hand. Today, you can emulate a PDP-11/70 in a browser. If you want to look at what Turing did at Bletchley Park, it’s there and you can play with it, but people don’t. Dave continued on to compare software development to jazz and talked about the importance of knowing the theory Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-pragmatic-programmers/id341623264?i=1000444208385 Website link: https://changelog.com/podcast/352 STACEY BARR ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Stacey Barr with host Dave Stachowiak. Stacey spoke about performance measurement in business and I wish more people understood the things she had to say. Stacey says that humans are not particularly good at judging how things change through time, but performance metrics can do that for us. Performance metric numbers also help us make comparisons a lot more reliably than we can without them. Measurement is about filling the gap in human perception so that we can know with a lot more certainty what’s really happening with the results we’re trying to achieve in our business. Dave asked what kinds of mistakes people make around performance measurement. Stacey says that there are a few and the first place you’ll see them is in the KPI column of a corporate plan. A common one is initiatives. An initiative usually describes an action or a project that has been chosen to improve performance. For example, if your goal is to improve customer loyalty, you may have an initiative to implement a customer relationship management system. That’s not a measure. An initiative is not evidence that you’ve changed anything for the better. Next, she talked about milestones. She says that a milestone is about getting something done by a particular point in time. A milestone might be, “We want to meet the medical council requirements for re-accreditation by June of next year.” These are commonly mistaken for performance measures but she asks, “Would the achievement of this milestone really change anything?” A whole lot of things may have gotten in the way that made that date no longer an appropriate date or that action no longer an appropriate action. A milestone as performance measure focuses us too much on ticking boxes and expending effort, and that takes us away from what we really need to focus on, which is to influence something to make it better. When a milestone is the performance measure, we’re not checking whether the activities are the right activities or the best activities. She then spoke about customer surveys. A common problem she says is that many will create a customer survey without thinking about the performance measures they need that survey to supply the data for. She also talked about “management speak” or “business jargon” and mentioned Don Watson’s book Death Sentences (https://www.amazon.com/Death-Sentences-Management-Speak-Strangling-Language/dp/1592401406) where he calls these words “weasel words.” She says these words sound important, sophisticated, and meaningful, but they are empty of meaning. She went on to give examples: holistic, effective, efficient, accountable, reliable, quality, impact, and sustainability. When you see these weasel words in the names of measures, you’ve identified a mistake because people won’t know what the weasel word truly means, they won’t know how to quantify it, and they won’t know what data to go after. She also made a great point about the value of ensuring that we are measuring certain metrics frequently enough. Measuring frequently enough is important because it allows us to distinguish between a pattern of natural variability and changes to that pattern. Finally, she told a story about presenting some research she was proud of to a committee and not getting the result she expected. I found this story extremely relatable. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/419-performance-measurement-that-gets-results-stacey/id458827716?i=1000444467235 Website link: https://coachingforleaders.com/podcast/performance-measurement-results-stacey-barr/ NIC SEMENTA ON DRUNKEN PM The Drunken PM podcast featured Nic Sementa with host Dave Prior. Nic is an Agilist whose expertise is in dynamic funnel development (understanding the pieces that make up marketing and sales funnels) and the psychology of the sale. He and his business partner speak about Agile marketing, the conscious communication code, and personal agility. Dave asked Nic how he learned about the language of persuasion. Nic says he’s a firm believer in building on your strengths and considers talking one of his strengths and says his talking skills have gotten him out of fist fights. He talked about subtly taking control of conversation using “pace, pace, lead.” He says we’re hardwired to either run away or attack back when conflict starts, but what you should do instead is run with your opponent. He says it is like a conversational rope-a-dope. You agree with them, you gain control of the conversation by matching the other person’s speed, and then you lead. If they come in fast and fired up, you agree with them while also being fast and fired up, then once they start agreeing with you, you slow down and lead the pace of the conversation. Dave asked how you avoid getting swept up in your own flight-or-fight reflex. Nic says you have to not take anything personally, not even a personal attack. As soon as you take something personally, you lose your ability to act. Instead, he says, you want to suck all the emotions out of the conversation and deal only with objectivity. He says that once you take away the emotions most people become quite rational. You’re not trying to take control of the other person, just their emotions. Dave asked Nic how he developed these skills and Nic explained that it was part of his upbringing to need to develop these skills. Nic described his childhood family life as a place where “Easter egg hunts can turn into knife fights,” so dealing with conflict came naturally to him. Dave asked what he can teach the rest of us who don’t have as much experience with conflict. He says you have to remind yourself that you are not a moral authority and therefore your opinion isn’t what matters; the objective situation is what matters. We’re trained that when something happens, we assume that that something is happening to us. For example, when a TV is louder than we like, we assume that the TV is too loud. He says we should remind ourselves we are not a moral authority with the simple phrase, “than I would like.” For example, when you’re perceiving a conflict and you are thinking, “Man, this guy is angry and he is loud and the situation is horrible,” instead think, “This guy is angrier than I would like, and louder than I would like, and the situation is worse than I would like, but what actually is going on?” Dave asked about non-violent communication. Nic described it as coming from the writings of Dr. Marshall Rosenberg about people’s natural tendency to speak in a way that implies a high level of moral authority, disconnects them from what is actually going on, and puts them in a position where they are judging others on a consistent basis and taking everything personally. Dr. Rosenberg wrote a curriculum to give people tools to combat this tendency. Nic used these tools to deal with the complicated situations in his personal and professional life without changing his own personality. He says you don’t have to be an nth-degree yogi who doesn’t eat dairy, meat, or sugar and meditates fourteen hours a day to use non-violent communication. You can be a hard-nosed sales dog and use the same tools without dropping your tone to a position of weakness. Nic says his own epiphany moment for non-violent communication was realizing that it was designed to give you power with people instead of power over people. This connects strongly with the notion of deconstructive criticism in How The Way We Talk Can Change The Way We Work (https://www.amazon.com/How-Talk-Change-Work-Transformation/dp/078796378X) by Kegan and Lahey. Dave asked Nic how he avoids thinking that he knows what people need. Nic says being objective helps and so does thinking, “Just because you can doesn’t mean you should.” Nic related a story of a business partner that used to ask Nic everyday, “What is one less thing we could do and still make the same money?” Most people are focused instead on doing more, Nic says, because most people forget the Pareto Principle or 80/20 rule. They also forget the Peter Principle and put themselves above their level of competency. They ended the conversation with Dave asking Nic for some final tips on communication. Nic says that being able to truly communicate well with your team comes from you understanding that, in addition to the conversations that you have with everybody else, you have another that happens with yourself. One of the most important benefits of telling the people around you why you care about them, why you appreciate them, and what their strengths are, is that, by doing so, you remind yourself. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-language-of-persuasion-w-nic-sementa/id1121124593?i=1000443404883 SoundCloud link: https://soundcloud.com/drunkenpmradio/the-language-of-persuasion-w-nic-sementa CHRISTOPHER AVERY ON AGILE UPRISING The Agile Uprising podcast featured Christopher Avery with host Brad Stokes. Christopher says that he has been fascinated with the psychology of cause and effect for the past thirty years. That interest produced a pattern called the Responsibility Process that is about processing thoughts about taking and avoiding ownership. We tend to like owning the stuff that we think we caused intentionally and is good and we tend to not like owning the stuff that we don’t like and we tend to think such things were caused, not by us, but by something external. Christopher says that the Responsibility Process is valuable for anyone who wants to live a happier life, be more emotionally free, experience the power of real choices in every situation, and be more effective and valuable. Christopher asks us to imagine a stack of words and phrases starting at the bottom with the phrase “lay blame,” then “justify,” “shame,” “obligation,” and finally, “responsibility.” Every time something goes wrong, even if you are just tripping over a crack in the sidewalk, it produces a little bit of angst or anxiety and our mind tries to help us cope by starting at the bottom of the stack and asking, “Who did this to me? Who caused this? Who put the crack in the sidewalk?” The lay blame state has its own cause-effect logic. It makes us think that we are experiencing the effect and the cause is coming from outside of us. For the anxiety to go away, somebody else has to change. By coincidence, this is practically the same topic that Nic Sementa delved into in the Drunken PM podcast I referenced earlier. If we recognize that we are in the lay blame state, we may graduate to the justify state. If we transcend that state, we graduate to the shame state where we don’t blame somebody else but blame ourselves. This state is full of self-punishment and self-loathing. If we realize that it is a choice we are making to stay in the shame state, we can graduate to the state of obligation. This is the state of feeling burdened in a process, a flow, or a promise. It is only when we refuse to feel trapped that we can enter the state of responsibility, where you are owning your ability and power to create, choose, and attract. Christopher says the state of responsibility is always accessible to us. If we practice the responsibility process, we can get to the responsibility state more quickly. Brad pointed out that the obligation state could easily be confused with the responsibility state. Christopher says this is exactly right and before we had the notion of these various states, the word responsibility was used to represent all of them. Christopher says that, for much of our lives, authorities have been reinforcing the idea that we should beat ourselves up when we make a mistake (shame) and do what we’re “supposed” to do even if we despise it (obligation). In obligation, we build up resentment against who or what has us trapped. We resent the mortgage, the kids, the needy elderly parents, and the boss. If you have been making decisions in your life for more than a few years, he says, then you are the architect of your own life and it is a product of your choices. From there Christopher goes on to say that your life is a product of your filters which may be caused by your environment, parents, church, schools, and neighborhoods. He then asks, “Do you want to defend those filters or examine them?” I see another connection here to the work of Robert Kegan and Lisa Lahey, this time in their book Immunity To Change (https://www.amazon.com/Immunity-Change-Potential-Organization-Leadership/dp/1422117367), which talks about examining the hidden assumptions that prevent us from changing things within ourselves even when we desperately want to change them. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-responsibility-process-with-christopher-avery/id1163230424?i=1000443858617 Website link: http://agileuprising.libsyn.com/the-responsibility-process-with-christopher-avery STEVE POLING ON MAINTAINABLE The Maintainable podcast featuring Steve Poling with host Robby Russel. Steve and Robby talked about technical debt. Steve says he’s been on projects where the tech debt got so bad that they engaged in rewrites, which he calls declaring bankruptcy. Steve suggests that the enduring popularity of technical debt as a metaphor is because it works to explain the tax on engineering velocity in terms that business people understand. It accumulates, it gets worse, and we want to pay it down. Robby asked about what processes Steve has used to keep on top of tech debt. Steve started by describing the anti-pattern from the quote above, which reminds me of the Joel Spolsky essay, Things You Should Never Do, Part 1, in which Spolsky spoke about the downsides of rewriting from scratch. Steve says he drank the test-driven development Kool-aid and he now believes that if you do the red-green-refactor of TDD, you can prevent the accumulation of tech debt. Without the refactor step, however, technical debt will continue to accumulate. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/steve-poling-the-real-enemy-is-murphy/id1459893010?i=1000444476559 Website link: https://maintainable.fm/episodes/steve-poling-the-real-enemy-is-murphy-vSKLVY5H LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

Episode 373: Joel Spolsky on Startups: Growth, and Valuation

Software Engineering Radio - The Podcast for Professional Software Developers

Play Episode Listen Later Jul 18, 2019 51:24

Joel Spolsky (“Joel on Software”), founder and CEO of Stack Overflow, discusses lessons of building successful software companies. Host Nate Black spoke with Joel about the venture funded “land grab” situations vs. “bootstrapping with profitability”. How do venture capitalists think and how can you make fundraising easier? What’s the strategy to keep as much ownership […]

Episode 373: Joel Spolsky on Startups Growth, and Valuation

Software Engineering Radio - The Podcast for Professional Software Developers

Play Episode Listen Later Jul 18, 2019 51:24

Joel Spolsky on founding Stack Overflow, land grabs vs. bootstrapping with profitability, raising more money using proof points, what developers and companies get massively wrong, choosing your next job, and how to ask and answer on Stack Over

growth blog startups jobs capital remote venture stack valuations overflow stack overflow joel spolsky

Learning Through Action

Troubleshooting Agile

Play Episode Listen Later Jul 3, 2019 16:22

A listener question about running a Troubleshooting Agile study group inspires advice on keeping your learning from becoming lunchtime entertainment, as well as surprisingly relevant stories about a pottery class, a management seminar, and the Israeli military. SHOW LINKS: - Joel's tweet requesting advice on his study group: https://twitter.com/joelchippindale/status/1143137854278840321 - Our series on the twelve agile principles: https://soundcloud.com/troubleshootingagile/the-importance-of-the-agile-principles - Pottery story from Art & Fear: https://www.amazon.com/exec/obidos/ASIN/0961454733/ via https://stratechery.com/2015/buzzfeed-important-news-organization-world/ - Joel Spolsky on Fire and Motion: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ - Reg Revans on action and learning: http://actionlearning.academy/benefits.html *** We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us: see link on troubleshootingagile.com Tweet us: twitter.com/TShootingAgile Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

fear learning art israel action fire israelis motion pottery asin joel spolsky

A Wabi-Sabi Technology Age

Breaking Smart

Play Episode Listen Later Jun 21, 2019 10:13

Since many of you have been suggesting for years that I do a Breaking Smart podcast, I figured I’d do a little experiment and try out the podcasting widget in Substack. If this works well, I’ll start mixing things up a bit and do a mix of text posts and podcast episodes. This is an unrehearsed, unedited, live 10-minute recording. Apologies for the 15 seconds of siren noise outside my apartment at around the 6:22 mark. I’m not sure exactly how you’d get the podcast into your listening app, but presumably there’s a way. I think I’m supposed to do stuff to submit it to Apple or something. Here’s the podcast feed URL if that helps: https://api.substack.com/feed/podcast/9973.rssIn this first short episode, I talk about how the Digital Age embodies a wabi-sabi approach to technology, where the Industrial Age embodied an ethos based on the pursuit of a “like-new” state. Let me know what you think! Some links for stuff I talk about are below the image.Image Credit: Kintsugi bowl, CC-BY-SA 4.0 by Ruthann HurwitzShow notes:Joel Spolsky post Things You Should Never Do, on why “throw one away” is a bad ideaOriginal Frederick Brooks argument that you should plan to throw one away is from The Mythical Man MonthWabi-Sabi and Kintsugi Get full access to Breaking Smart at breakingsmart.substack.com/subscribe

apple technology apologies substack digital age cc by sa wabi sabi industrial age joel spolsky rssin

E918: Stack Overflow CEO & co-founder Joel Spolsky shares lessons growing his groundbreaking Q&A site to 100m+ monthly visitors, insights on leading, pivoting, selling Trello, engaging with VCs, becoming focused & what he’s looking for in his

This Week in Startups

Play Episode Listen Later Apr 9, 2019 53:11

The post E918: Stack Overflow CEO & co-founder Joel Spolsky shares lessons growing his groundbreaking Q&A site to 100m+ monthly visitors, insights on leading, pivoting, selling Trello, engaging with VCs, becoming focused & what he’s looking for in his replacement as CEO appeared first on This Week In Startups.

ceo lessons co founders startups selling engaging focused visitors pivoting 100m groundbreaking vcs trello stack overflow this week in startups joel spolsky

E918: Stack Overflow CEO & co-founder Joel Spolsky shares lessons growing his groundbreaking Q&A site to 100m+ monthly visitors, insights on leading, pivoting, selling Trello, engaging with VCs, becoming focused & what he’s looking for in his

This Week in Startups - Video

Play Episode Listen Later Apr 9, 2019 53:18

ceo lessons co founders selling engaging focused visitors pivoting 100m groundbreaking vcs trello stack overflow this week in startups joel spolsky

From the ‘Business of Software Conference' to running ‘The Marketing Meetup' with Joe Glover

The Events Podcast

Play Episode Listen Later Oct 11, 2018 51:38

Listen on: iTunes / Podbean / Stitcher / Spotify / YouTube / Sign up for our newsletter for more info on getting you started running amazing events. This podcast is brought to you by www.eventsframe.com - Effortless ticketing and attendee management with NO ticket fees....Make the switch from Eventbrite today ! Email dan@eventsframe.com with the subject line ‘PODCAST' for a special discount code. On this week's episode of ‘The Events Podcast' I spoke with Joe Glover from The Marketing Meetup and it was a really interesting chat. Joe started off doing marketing for the ‘Business of Software Conference', which is a big deal for the SaaS community, where he ran the marketing for the UK and USA conferences. They were lucky in that one of the founders was Joel Spolsky who already had a huge audience and this always makes promoting an event 10x easier. Their main marketing method they used was recorded videos of all the speakers at the conference and releasing them gradually throughout the year, with email opt in (using Wistia). Once they had email addresses they then marketed the conference via an email sequence. We discussed event location and how they went for the approach of keeping the same venue so it had a familiar homely feel that attendees wanted to make a regular part of their year. I have mixed feelings on this as sometimes a new venue or new city each year keeps the conference feeling fresh. Moving on Joe founded The Marketing Meetup as an event in Cambridge to meet other marketers and had 30 people to the first event. He promotes with Meetup.com and LinkedIn (adding friend requests). Joe monetises the event with sponsors,. He drew up a list of companies, then approached the CEO (again on LinkedIn). He made the events monthly and holds the event at a sponsors offices so no fees and another sponsor pays for drinks. He has a Facebook community which he has to approve members and he finds this is really useful. Joe has now started a ‘franchise' model for other cities where other people run the events and find the sponsors and keep 70% of the revenue. ALso rally interesting that Joe does all this while working a full time job I hope you enjoyed the podcast and if you did please leave us an iTunes review it really means a lot to us ! Finally please join our Facebook Community of #eventprofs to keep the learning going You can email me at dan@eventsframe.com Get in touch with me via dantaylor.me More info about Joe is below and if you're into marketing he'd love to her from you @josepheglover joe@themarketingmeetup.com themarketingmeetup.com Sign up to get exclusive offers and updates on our latest feature releases!

united states ceo business uk marketing moving running conference software cambridge saas meetup glover eventbrite effortless wistia joel spolsky

27. Kodtester med Henrik Enström

Techrekpodden

Play Episode Listen Later Sep 23, 2018 47:05

Att man vill kolla kandidaters tekniska nivå i en rekrytering känns självklart, men hur gör man det på bästa sätt? Carl-Johan och Henrik Enström tar en djupdykning i ämnet kodtester. Henrik, som är VD och grundare på Future skill, är även expert på smarta sätt att jobba med kodtester och i det här avsnittet delar han med sig av best practices för att lyckas. Vi får också höra om Henriks karriär, hur en idealisk rekryteringsprocess går till och vad som enligt Henrik är viktigast att tänka på som chef. Läs mer om Future skill Länkar till de studier och tester Henrik nämner i avsnittet: Sofia Sjöbergs studie Joel Spolsky-testet Valves personalhandbok IAT-testet Är ditt företag i behov av IT-kompetens, hör av dig till cj@ants.se eller läs mer om oss på Ants.se. Linkedin Facebook Instagram

future tech att ants vd valves henriks iat carl johan rekrytering joel spolsky gteborg sofia sj henrik enstr

Ep. 42 - How to write a good design doc

The freeCodeCamp Podcast

Play Episode Listen Later Aug 13, 2018 14:53

As a software engineer, it's your responsibility to write a good design doc so that your team knows how to solve the problem you're addressing. But what makes a design doc good, what should you include, and how should you write it? Angela shares all her tips so you can make your design docs as effective and helpful as possible. Written by Angela Zhang: https://twitter.com/zhangelaz Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2vAL4io Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: As a software engineer, I spend a lot of time reading and writing design documents. After having gone through hundreds of these docs, I’ve seen first hand a strong correlation between good design docs and the ultimate success of the project. This article is my attempt at describing what makes a design document great. The article is split into 4 sections: Why write a design document What to include in a design document How to write it The process around it Why write a design document? A design doc — also known as a technical spec — is a description of how you plan to solve a problem. There are lots of writings already on why it’s important to write a design doc before diving into coding. So all I’ll say here is: A design doc is the most useful tool for making sure the right work gets done. The main goal of a design doc is to make you more effective by forcing you to think through the design and gather feedback from others. People often think the point of a design doc is to to teach others about some system or serve as documentation later on. While those can be beneficial side effects, they are not the goal in and of themselves. As a general rule of thumb, if you are working on a project that might take 1 engineer-month or more, you should write a design doc. But don’t stop there — a lot of smaller projects could benefit from a mini design doc too. Great! If you are still reading, you believe in the importance of design docs. However, different engineering teams, and even engineers within the same team, often write design docs very differently. So let’s talk about the content, style, and process of a good design doc. What to include in a design doc? A design doc describes the solution to a problem. Since the nature of each problem is different, naturally you’d want to structure your design doc differently. To start, the following is a list of sections that you should at least consider including in your next design doc: Title and People The title of your design doc, the author(s) (should be the same as the list of people planning to work on this project), the reviewer(s) of the doc (we’ll talk more about that in the Process section below), and the date this document was last updated. Overview A high level summary that every engineer at the company should understand and use to decide if it’s useful for them to read the rest of the doc. It should be 3 paragraphs max. Context A description of the problem at hand, why this project is necessary, what people need to know to assess this project, and how it fits into the technical strategy, product strategy, or the team’s quarterly goals. Goals and Non-Goals The Goals section should: describe the user-driven impact of your project — where your user might be another engineering team or even another technical system specify how to measure success using metrics — bonus points if you can link to a dashboard that tracks those metrics Non-Goals are equally important to describe which problems you won’t be fixing so everyone is on the same page. Milestones A list of measurable checkpoints, so your PM and your manager’s manager can skim it and know roughly when different parts of the project will be done. I encourage you to break the project down into major user-facing milestones if the project is more than 1 month long. Use calendar dates so you take into account unrelated delays, vacations, meetings, and so on. It should look something like this: Start Date: June 7, 2018 Milestone 1 — New system MVP running in dark-mode: June 28, 2018 Milestone 2 - Retire old system: July 4th, 2018 End Date: Add feature X, Y, Z to new system: July 14th, 2018 Add an [Update] subsection here if the ETA of some of these milestone changes, so the stakeholders can easily see the most up-to-date estimates. Current Solution In addition to describing the current implementation, you should also walk through a high level example flow to illustrate how users interact with this system and/or how data flow through it. A user story is a great way to frame this. Keep in mind that your system might have different types of users with different use cases. Proposed Solution Some people call this the Technical Architecture section. Again, try to walk through a user story to concretize this. Feel free to include many sub-sections and diagrams. Provide a big picture first, then fill in lots of details. Aim for a world where you can write this, then take a vacation on some deserted island, and another engineer on the team can just read it and implement the solution as you described. Alternative Solutions What else did you consider when coming up with the solution above? What are the pros and cons of the alternatives? Have you considered buying a 3rd-party solution — or using an open source one — that solves this problem as opposed to building your own? Monitoring and Alerting I like including this section, because people often treat this as an afterthought or skip it all together, and it almost always comes back to bite them later when things break and they have no idea how or why. Cross-Team Impact How will this increase on call and dev-ops burden? How much money will it cost? Does it cause any latency regression to the system? Does it expose any security vulnerabilities? What are some negative consequences and side effects? How might the support team communicate this to the customers? Discussion Any open issues that you aren’t sure about, contentious decisions that you’d like readers to weigh in on, suggested future work, and so on. Detailed Scoping and Timeline This section is mostly going to be read only by the engineers working on this project, their tech leads, and their managers. Hence this section is at the end of the doc. Essentially, this is the breakdown of how and when you plan on executing each part of the project. There’s a lot that goes into scoping accurately, so you can read this post to learn more about scoping. I tend to also treat this section of the design doc as an ongoing project task tracker, so I update this whenever my scoping estimate changes. But that’s more of a personal preference. How to write it Now that we’ve talked about what goes into a good design doc, let’s talk about the style of writing. I promise this is different than your high school English class. Write as simply as possible Don’t try to write like the academic papers you’ve read. They are written to impress journal reviewers. Your doc is written to describe your solution and get feedback from your teammates. You can achieve clarity by using: Simple words Short sentences Bulleted lists and/or numbered lists Concrete examples, like “User Alice connects her bank account, then …” Add lots of charts and diagrams Charts can often be useful to compare several potential options, and diagrams are generally easier to parse than text. I’ve had good luck with Google Drawing for creating diagrams. Pro Tip: remember to add a link to the editable version of the diagram under the screenshot, so you can easily update it later when things inevitably change. Include numbers The scale of the problem often determines the solution. To help reviewers get a sense of the state of the world, include real numbers like # of DB rows, # of user errors, latency — and how these scale with usage (remember your Big-O notations?). Try to be funny A spec is not an academic paper. Also, people like reading funny things, so this is a good way to keep the reader engaged. Don’t overdo this to the point of taking away from the core idea though. If you, like me, have trouble being funny, Joel Spolsky (obviously known for his comedic talents…) has this tip: One of the easiest ways to be funny is to be specific when it’s not called for [… Example:] Instead of saying “special interests,” say “left-handed avacado farmers.” Do the Skeptic Test Before sending your design doc to others to review, take a pass at it pretending to be the reviewer. What questions and doubts might you have about this design? Then address them preemptively. Do the Vacation Test If you go on a long vacation now with no internet access, can someone on your team read the doc and implement it as you intended? The main goal of a design doc is not knowledge sharing, but this is a good way to evaluate for clarity so that others can actually give you useful feedback. Process Ah yes, the dreaded P-word. Design docs help you get feedback before you waste a bunch of time implementing the wrong solution or the solution to the wrong problem. There’s a lot of art to getting good feedback, but that’s for a later article. For now, let’s just talk specifically about how to write the design doc and get feedback for it. First of all, everyone working on the project should be a part of the design process. It’s okay if the tech lead ends up driving a lot of the decisions, but everyone should be involved in the discussion and buy into the design. So the “you” throughout this article is a really plural “you” that includes all the people on the project. Secondly, the design process doesn’t mean you staring at the whiteboard theorizing ideas. Feel free to get your hands dirty and prototype potential solutions. This is not the same as starting to write production code for the project before writing a design doc. Don’t do that. But you absolutely should feel free to write some hacky throwaway code to validate an idea. To ensure that you only write exploratory code, make it a rule that none of this prototype code gets merged to master. After that, as you start to have some idea of how to go about your project, do the following: Ask an experienced engineer or tech lead on your team to be your reviewer. Ideally this would be someone who’s well respected and/or familiar with the edge cases of the problem. Bribe them with boba if necessary. Go into a conference room with a whiteboard. Describe the problem that you are tackling to this engineer (this is a very important step, don’t skip it!). Then explain the implementation you have in mind, and convince them this is the right thing to build. Doing all of this before you even start writing your design doc lets you get feedback as soon as possible, before you invest more time and get attached to any specific solution. Often, even if the implementation stays the same, your reviewer is able to point out corner cases you need to cover, indicate any potential areas of confusion, and anticipate difficulties you might encounter later on. Then, after you’ve written a rough draft of your design doc, get the same reviewer to read through it again, and rubber stamp it by adding their name as the reviewer in the Title and People section of the design doc. This creates additional incentive and accountability for the reviewer. On that note, consider adding specialized reviewers (such as SREs and security engineers) for specific aspects of the design. Once you and the reviewer(s) sign off, feel free to send the design doc to your team for additional feedback and knowledge sharing. I suggest time-bounding this feedback gathering process to about 1 week to avoid extended delays. Commit to addressing all questions and comments people leave within that week. Leaving comments hanging = bad karma. Lastly, if there’s a lot of contention between you, your reviewer, and other engineers reading the doc, I strongly recommend consolidating all the points of contention in the Discussion section of your doc. Then, set up a meeting with the different parties to talk about these disagreements in person. Whenever a discussion thread is more than 5 comments long, moving to an in-person discussion tends to be far more efficient. Keep in mind that you are still responsible for making the final call, even if everyone can’t come to a consensus. In talking to Shrey Banga recently about this, I learned that Quip has a similar process, except in addition to having an experienced engineer or tech lead on your team as a reviewer, they also suggest having an engineer on a different team review the doc. I haven’t tried this, but I can certainly see this helping get feedback from people with different perspectives and improve the general readability of the doc. Once you’ve done all the above, time to get going on the implementation! For extra brownie points, treat this design doc as a living document as you implement the design. Update the doc every time you learn something that leads to you making changes to the original solution or update your scoping. You’ll thank me later when you don’t have to explain things over and over again to all your stakeholders. Finally, let’s get really meta for a second: How do we evaluate the success of a design doc? My coworker Kent Rakip has a good answer to this: A design doc is successful if the right ROI of work is done. That means a successful design doc might actually lead to an outcome like this: You spend 5 days writing the design doc, this forces you to think through different parts of the technical architecture You get feedback from reviewers that X is the riskiest part of the proposed architecture You decide to implement X first to de-risk the project 3 days later, you figure out that X is either not possible, or far more difficult than you originally intended You decide to stop working on this project and prioritize other work instead At the beginning of this article, we said the goal of a design doc is to make sure the right work gets done. In the example above, thanks to this design doc, instead of wasting potentially months only to abort this project later, you’ve only spent 8 days. Seems like a pretty successful outcome to me.

english design goals simple leaving write original mvp roi commit retire monitoring milestone aim charts concrete db pro tips eta big o bribe quip good design sres joel spolsky google drawings technical architecture design doc

iPS 250: iOS Architecture at Scale with Parveen Kaler

The iPhreaks Show

Play Episode Listen Later Aug 2, 2018 40:37

Panel: Jaim Zuber Gui Rambo In today’s episode, the iPhreaks panel talks to Parveen Kaler about iOS architecture at scale. Parveen has been doing mobile development, specifically iOS development, for almost 10 years now, and he previously used to work in the video games industry. They talk about the difference between scale when it comes to dollars and revenue, the pull request process, and what good architecture at scale is. They also touch on creating uniform views, object mappers, and more! In particular, we dive pretty deep on: Parveen Intro Used to work with PSP video game development iOS Architecture At Scale - types of scale His talk at AltConf Is there a difference scale w/ dollars and scale /w customers? What are major differences from coming from a large company? Do you run into issues with many customers? Pull Requests and Release Train Release Manager What is good architecture at scale? Definition of good architecture Three things lead to good architecture What are coding style differences? You want to unify models Unification really matters How do you create uniform views? How do you work when code you want to change is handled by another team? Unified router framework Object Mapper How do you combat long compile times? Does Xcode improve compile times? Does Swift provide advantages vs Objective-C? AB Testing at Scale? And much, much more! Links: His talk at AltConf Xcode parveenkaler.com @kaler Parveen’s GitHub Smartful Studios Sponsors: FreshBooks Loot Crate Picks: Jaim Iron Maiden Pinball Gui Things You Should Never Do, Part I by Joel Spolsky Parveen US Passport

scale panel ios definition architecture github unified psp unification freshbooks loot crates xcode objective c ab testing pull requests kaler joel spolsky altconf release manager iphreaks

iPS 250: iOS Architecture at Scale with Parveen Kaler

Devchat.tv Master Feed

Play Episode Listen Later Aug 2, 2018 40:37

scale panel ios definition architecture github unified psp unification freshbooks loot crates xcode objective c ab testing pull requests kaler joel spolsky altconf release manager iphreaks

158 Is Your To-Do List Too Long?

Inspiring Greatness

Play Episode Listen Later Jul 16, 2018 8:37

Welcome to episode 158! Welcome to episode 158 where we share a story from the founder of Trello Joel Spolsky. This story caught my attention one my guests on this podcast have recommend Trello several times as their favourite tech tool. Secondly because it’s about doing things different not better. Is your to-do list too long? Joel Spolsky found a way to solve his to-do list. If that wasn’t reward enough, he sold his solution - Trello - to Atlassian for $425 million... Maxum Corporation - Inspiring Greatness Show Notes: http://maxumcorp.com.au/podcasts/

trello atlassian joel spolsky

PG Podcast - Episode 37 - Henry Zhu on humans of open-source software

Philip Guo - podcasts and vlogs - pgbovine.net

Play Episode Listen Later Jun 12, 2018

Twitter: https://twitter.com/pgbovineSupport with Patreon, PayPal, or credit/debit: http://pgbovine.net/support.htmhttp://pgbovine.net/PG-Podcast-37-Henry-Zhu.htm- [Things You Should Never Do, Part I - Netscape rewriting their entire codebase](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/) by Joel Spolsky- [Google and HTTP](http://this.how/googleAndHttp/) by Dave Winer- [#SmooshGate FAQ](https://developers.google.com/web/updates/2018/03/smooshgate)- [Diligence, Patience, and Humility](https://www.oreilly.com/openbook/opensources/book/larry.html) by Larry Wall- [Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure](https://www.fordfoundation.org/library/reports-and-studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/) by Nadia Eghbal- [PG Podcast - Episode 35 - Audrey Boguchwal + Nadia Eghbal on sustainable online communities](http://pgbovine.net/PG-Podcast-35-Audrey-Boguchwal-and-Nadia-Eghbal.htm)Recorded: 2018-06-13 (2)

google humility humans paypal roads diligence open source software dave winer joel spolsky nadia eghbal henry zhu larry wall pg podcast

ajitofm 25: Never the same team twice

ajitofm

Play Episode Listen Later Jun 3, 2018 67:43

ryuzeeさん、songmuさん、katzchangさん、nishigoriさんと継続的インテグレーション、データベースマイグレーション、コミットログ、採用、スクラムなどについて話しました。 Effective DevOps - 4本柱による持続可能な組織文化の育て方 The DevOps 逆転だ! - 究極の継続的デリバリー入門 Kubernetes Coveralls Flyway git blameでプルリクエストの番号を表示する Slackの分報チャンネル使うのやめた Square の採用プロセスについて採用面接ゲリラガイド(version 3.0) - Joel Spolsky / 青木靖訳レゴ®ではじめるスクラム体験/レゴスクラム茶室 - Wikipedia Attractor Inc. この回は @brtriver にマスタリングを依頼しました。フィードバックもお待ちしております！ https://ajito.fm/form/ または Twitter: #ajitofm までどうぞ。

wikipedia e3 square slack devops kubernetes a6 never the same flyway joel spolsky coveralls

Interview with David Heinemeier Hansson

rewrite david heinemeier hansson dhh joel spolsky

Play Episode Listen Later Feb 9, 2018 58:17

Joel Spolsky says: "Never rewrite your software from scratch". DHH says: "Rewrite your damn software". In this interview, he explains why. --- Send in a voice message: https://anchor.fm/business-of-software/message

211: 4 weeks, 3 days

Embedded

Play Episode Listen Later Aug 17, 2017 79:47

Dennis Jackson spoke with us about making the career shift from software to embedded. Dennis buys James Grenning’s Test Driven Development in Embedded C for his new hires and often recommends Elecia’s Making Embedded Systems. His tip that everyone should know was “Learn make!” and he has a reference for that: Why Use Make. He suggested Joel Spolsky’s reading lists from Joel On Software, even the ones that don’t obviously apply. Additional suggested-reading articles: 30 Pitfalls for Real Time Systems (part 1 and part 2) Rules for defensive C programming Why are you still using C What every computer scientist should know about floating point arithmetic The Power of Ten -- 10 Rules for Writing Safety Critical Code . In his previous appearance on Embedded (#25: Don’t Be Clever), we talked about code complexity and measuring cyclomatic complexity. At that time he wanted a tool to monitor the code’s status. He has since found one: pmccabe. Dennis currently works at Element Science.

power pitfalls embedded test driven development joel spolsky dennis jackson elecia

MRS 015 My Ruby Story Marc-Andre Cournoyer

All Ruby Podcasts by Devchat.tv

Play Episode Listen Later Aug 16, 2017 49:32

MRS 016 Marc-Andre Cournoyer Today's episode is a My Ruby Story with Marc-Andre Cournoyer. He was the creator of the Thin web server and he will be speaking at the Ruby Dev Summit. On this episode, Marc talked about how he got into programming and Ruby. Listen to learn more about Marc! [01:05] – Introduction to Marc Marc is the creator of the Thin web server, one of the most popular Ruby server. He also had some minor contributions to Ruby. One of them is called Tinyrb, which is a small Ruby VM. Then, he wrote a book about creating your own programming language. He will be speaking at Ruby Dev Summit. [02:45] – How did you get into programming? Marc’s first experience with a computer was when he’s around 8 or 9 years old. It was on the early 1990s. His parents won a Commodore 64 at the grocery store. He got bored really fast with the games so he looked at other things. One of them is the Commodore Basic. You could not save on a Commodore 64 if you didn’t add the tape recorder so he would have to start again each time. He also went to a library and got some books about Commodore 64 programming. Eventually, he started creating his own simple programs. A few years later, Marc got a Pentium 2. It was around 1995. He saved money and bought himself Microsoft Visual Basic 4. It has the UI with the drags and drops where you drop buttons and timers on a page. You would double click the buttons and you would open a window where you can put your code. He had about hundred projects on that machine. [05:35] – How old were you when you got into VB? Marc was 14 or 15 years old when he got into VB. [06:05] – How did you get into Ruby? After that, it has become Marc’s career choice to become a programmer. He went to university. After that, he got his first job in 2002 doing Visual Basic 4 application that runs inside Microsoft Office suite. He also did a little bit of Java and .NET. He didn’t enjoy programming, he started losing my passion, and he stopped doing projects on the side. But he still kept on reading some books about programming. One of them is a book by Joel Spolsky, The Best Software Writing. It was published in 2005. The last chapter is an extract of Why’s (Poignant) Guide to Ruby, which was an introductory book about Ruby. Marc liked the syntax so he started practicing Ruby more. He started doing side projects again because it was fun programming Ruby. And then, he discovered Rails about a year later. Because of that, he created many other projects and got a job at a startup in Montreal. Picks Marc-Andre Cournoyer Cooperpress Framework: Torch Charles Max Wood Eventual Millionaire Coursera course on Machine Learning by Andrew Ng Ruby Dev Summit

montreal machine learning ui thin java rails commodore coursera microsoft office vb andrew ng visual basic pentium marc andre eventual millionaire joel spolsky charles max wood poignant guide ruby dev summit commodore basic

Sergio returns to discuss a presentation about incident management that he gave at the Tokyo Rubist Meetup. (Apologies about the poor audio quality.) Show NotesSlides from Sergio’s presentation ‘Do Not Panic!’Tokyo Rubyist MeetupChapter 14 - Managing Incidents of Google’s excellent Site Reliability Engineering book.The Joel Test: 12 Steps to Better Code. Step 1 is “Do you use source control?”Scaling your API with rate limiters on the Stripe Blog“The number one priority if you loose communication with your team is to reestablish communication with your team.” - Joel Spolsky at around 9:00 on the excellent, excellent Episode 36 of the Stack Exchange Podcast ‘We Got Hit by a Hurricane’Reddit: Accidentally destroyed production database on first day of a job…Discussion of the above on Hacker News

google apologies panic scaling api hacker news site reliability engineering joel spolsky

Joel Spolsky: CEO of Stack Overflow

Office Hours with Spencer Rascoff

Play Episode Listen Later Jun 15, 2017 30:49

As a founding member of several successful companies (Fog Creek, Trello) in the software development space, you could say that Joel Spolsky knows a bit about developers. On his popular online forum, Stack Overflow, developers ask more than 8,000 questions a day to a community of roughly 40 million developers who visit the site every month. Joel talks about software developers with a reverence normally reserved for philosophers: "Every day, developers get a chance to make a decision that's going to impact the world," he says. But with that power comes great responsibility, and managers have an important role to play in helping developers consider unintended consequences and use their power for good.

trello stack overflow joel spolsky fog creek

一三五、揭秘比尔·盖茨鲜为人知的12件轶事

科技最前沿，论天文物理人工智能数码编程大数据等

Play Episode Listen Later May 31, 2017 17:17

清風明月逍遥客 2017-05-23 17:20了不起的比尔·盖茨（Bill Gates）。从哈佛的辍学生，到微软的亿万富翁，再到全世界最慷慨的慈善家，在比尔·盖茨的发家过程中，他的身上被打上了各种标签，比如一个严肃的管理者，一个杰出的思想者，以及一个单纯的爱洗盘子的家伙。高中时，少年盖茨被教务处指派了一个任务，用学校的电脑系统创建一个课程表。借此机会，盖茨就把他感兴趣的所有女生都编排进了“他的课程表”里。在哈佛，比尔·盖茨从来没有出席过任何他注册过的课，反而在其它一些他极为感兴趣的课程上经常露面。不过感谢填鸭式的教育“魔法”，盖茨总还是能在最后的期末考试中拿到“A”的优秀成绩。20岁的比尔·盖茨解决了一道困扰学界30年的数学难题——“煎饼问题”（pancake sorting）。当时这个“煎饼”难题已经“卡在”数学界30年了，一直无人能解开，直到比尔·盖茨提出了一个令人惊叹的解题方法。那时，一位哈佛教授打电话给盖茨告诉他，他的解题方法未来将会在某个学术期刊上发表时，比尔·盖茨对此毫不关心，此时的他已经辍学去创建微软了。前哈佛教授克里斯托斯•潘帕莱米托（Christos Papadimitriou）回忆称：“两年以后，我打电话告诉他，我们的学术论文已经被一家很棒的数学期刊接受了，但盖茨表示完全不感兴趣。我当时的想法是‘这么聪明的学生，真是浪费了'。”比尔·盖茨经常开着他的保时捷911从阿尔伯克基办公室回他在西雅图的新家，他先后三次收到过超速罚单，其中两次还是来自同一个警察。过去，盖茨经常在阿尔伯克基沙漠边上，也就是微软的第一个办公室附近疯狂飙车，有一次他从朋友那借了一辆保时捷928超级跑车，最后那辆“可怜”的车几近报废，连汽车底盘都脱落了，花了一年才被修好。比尔·盖茨曾经能记住所有微软员工的车牌号码，并以此跟踪他们上下班考勤的状态。在接受采访时，盖茨曾说道，“我不得不谨慎地劝诫自己，不要用自己的标准去衡量他们有多努力工作”。“你知道吗？我清楚每个人的车牌号码，所以如果我去留心观察停车场的状况的话，我就能知道大家什么时候来的公司，又是什么时候离开公司的。直到后来公司逐渐成长到足够大的规模，我才逐渐松懈下了这个习惯。”为了保持高效工作，比尔·盖茨不得不从他的电脑中卸载掉扫雷游戏。盖茨曾一度非常痴迷于经典的Windows“扫雷游戏”，以至于后来他不得不从自己的办公电脑上卸载了它，以保证自己能高效地进行工作。当时有一名微软员工编写了一个计算机脚本，并用它超越了比尔·盖茨在扫雷游戏中所创下的记录，比尔·盖茨于是发了一封邮件，在邮件中他写道：“当机器做事比人更快时，我们要如何挽回我们作为人类的自尊？”比尔·盖茨一直到上世纪90年代还乘坐经济舱出差，和所有的微软员工一样执行公司规定的标准。到1990年时，微软公司已经蒸蒸日上了，但公司有政策规定员工出差旅行须乘坐经济舱，比尔·盖茨也不例外，他长期以来也一直在乘坐经济舱。“1990年时，我刚加入微软没多久，盖茨、几名Windows小组的员工和我一同从西雅图飞往纽约去参加几个客户的会议。那时Window 3.0系统刚推出没多久，虽然至今已时隔25年，但那时的微软已经是一个小有名气、欣欣向荣的公司了。但根据公司规定的政策，每名员工都须乘坐经济舱。所以，我就曾亲眼目睹盖茨出现在经济舱的中间位置。但他丝毫不在意这些，在整个飞行过程中，他一直在读书。那时，他还没像如今这样有名，所以乘坐经济舱对他来说也不算是什么麻烦事儿。看着盖茨先生亲自以身作则，给我这个当时的微软新人留下了很深刻的印象。”只需统计比尔·盖茨说脏话的次数，就可以掂量出他对一个新提案的看法。Stack Overflow的创始人乔尔·斯波尔斯基（Joel Spolsky）曾是微软早期时的一名员工。他曾在博客帖子中讲了一个段子：“那时候，我们常要做一件事叫‘盖茨复审'。基本上，每项重要的功能都需要经过盖茨的复审。在我的‘盖茨复审'会议上，我的小组中会专门安排一名员工，他在整个会议中的全部工作就是要准确地记录比尔·盖茨说脏话的次数。次数越少，就意味着这个提案越棒。‘4次'，脏话记录员有一次这样宣布道，然后大家一起感叹道：‘哇，这是我印象中的最低数字了。看来盖茨先生年龄大了，人也变得成熟温和了'。”当时，比尔·盖茨36岁。比尔·盖茨喜欢拷问员工。比尔·盖茨并不是真得想检查你的编程能力，他只是想确定你处在他的控制下。他的标准模式是问越来越难的问题，直到你承认你不知道，然后他就可以大声指责你没做好准备。没人知道如果你回答上来他所提出的最难问题之后会发生什么，因为那种事之前从没发生过……这才是重点。比尔·盖茨技术能力惊人，如果他信任某个人，他就不会在软件研发的事上插手。但你不能对他有一点胡扯，因为他是学编程出身的，是一个有真材实料的程序员。他编码了一款名叫DONKEY.BAS（《驴.BAS》）的小游戏。当微软首次向IBM公司授权DOS操作系统时，IBM公司要求盖茨和微软公司提供几款自带的小游戏。盖茨就和同事Neil Konzen加班到凌晨4时，终于编写出一款名叫DONKEY.BAS的简单小游戏，这款游戏需要你在驾驶时，躲避路上蹿出来的驴子。苹果公司的Mac小组在初次体验IBM笔记本电脑时，他们对DONKEY.BAS感到尴尬极了，他们很难相信比尔·盖茨会愿意在这种程序上留下他的名字。苹果早期的员工安迪·赫兹菲尔德（Andy Hertzfeld）曾经写道：“我们当时非常惊讶这么糟糕透顶的游戏竟然是由微软公司创始人与别人合伙编写的，而且他还想得到别人的好评。”比尔·盖茨喜欢自己来洗晚餐的盘子，并且他几乎天天乐此不疲。对此，盖茨自己解释称：“虽然有人愿意帮我洗，但是我很享受自己洗盘子的过程。”在采访中，比尔·盖茨曾迫使一名记者向他道歉。盖茨曾在一次采访中把自己反锁在卫生间里，并表示除非这名记者就刚才刁难他行为致歉，否则他拒绝出去。很久以前在This Week In Tech节目上，记者玛丽·乔·弗利（Mary Jo Foley）讲述了这段插曲：“这是个很有趣的事儿。当时，我正在世界计算机博览会上采访他，随行的还有其他几名记者，其中也包括约翰·道奇（John Dodge），道奇的一贯风格就是让别人出丑。当时，道奇为了使盖茨难堪，问了他一些愚蠢的问题，比如市场的定义。比尔·盖茨变得越来越生气，最后他站起身来走进了卫生间，并表示不愿再出来。盖茨说‘我不会出去，除非道奇道歉'。最后，道奇走到门前对他说了声对不起。然后，盖茨就出来了……过去的盖茨完全是另一个人，他做了父亲之后真的变了很多。过去，盖茨完全是个典型的无所畏惧的科技狂。后来他变得更像普通人了。所以，当我给别人讲盖茨过去的轶事时，人们总会问：‘比尔·盖茨？真的吗？'”

windows window ibm bill gates donkey bas stack overflow this week in tech mary jo foley joel spolsky andy hertzfeld john dodge

Heresy E2 - Kristen Habacht, VP Sales Trello on selling SaaS and Freemium products

Heresy

Play Episode Listen Later Jan 26, 2017 45:47

In this episode of the Heresy podcast we talk to Kristen Habacht, VP Sales at Trello. The conversation was recorded in the last week of December 2016, just days before Atlassian announced they were acquiring Trello for a whooping $425 million. During our conversation Kristen describes what the Sales team at Trello looks like and how that has changed during the two and a half years since she's been there. We also discuss their sales compensation, their recent growth and future plans as well as the challenges and opportunities they have faced selling a freemium product. ======================================================== Content and Timings: - 0:54 - 4:20 - Kristen talks about her sales career, how she met Joel Spolsky & Michael Pryor, the FogCreek days and how she eventually ended up as VP Sales at Trello - 5:00 - 6:50 - Selling Trello in the early days and how the pitch has changed - 7:20 - 12:10 - Kristen talks about Trello’s sales team, their culture, the importance of team cohesion, how they are structured and why - 12:10 - 18: 50 - The evolution of Trello’s sales team - how and why the team transitioned from a “full-stack” sales model to role specialisation, and how that helped with scaling - 18:53 - 21:00 - Kristen talks about “experiments” that did not work and lessons learned - 21:00 - 22:45 - The importance of Sales Ops - 23:00 - 24:15 - Kristen talks about recent growth and projections for the future - 24:25 - 27:35 - Trello’s commission structure - from, simple to simpler - and why Kristen changed their initial commission structure - 27:40 - 34:40 - The challenges of selling freemium products - why traditional qualification models such as BANT don’t work, what can reps do to create urgency and why there’s no sales “playbook” at Trello - 34:50 - 38:45 - SMB vs Enterprise sales at Trello - sales cycle duration and how the process differs - 39:00 - 42:15 - The challenges of managing a remote sales team and tips, and tools to make it work - 42:15 - 45:00 - Lessons learned at Trello & Kristen's best sales advice - the importance of being able to walk away ============================================================== Music credits: - Intro - Qvkata DLG, Duis Taban - Outro - Victor Hugo

music lessons sales selling products saas enterprise trello heresy smb atlassian freemium bant timings sales ops joel spolsky michael pryor

Checking in with Joel Spolsky who says I suck at Excel

ceo new york suck checking excel anil dash joel spolsky

Play Episode Listen Later Jan 5, 2017 31:31

I'm in New York this week checking in with Joel Spolsky from StackExchange/StackOverflow. Big things are happening in Joel's world. They've just hired Anil Dash to be the CEO of FogCreek and launched a new product. What's it like to be Joel and what's it like to NOT suck at Excel?

169: Your Blog Can Be Generated By Neural Networks (omo)

Rebuild

Play Episode Listen Later Dec 25, 2016 105:57

Hajime Morita さんをゲストに迎えて、達人プログラマーなどについて話しました。 Show Notes Rebuild: Supporter Naoya Ito: "業界の悪習: 新人に10冊も20冊も自分が読んだ本を薦める" 新装版達人プログラマー職人から名匠への道 | Amazon 新装版達人プログラマー職人から名匠への道 | オーム社 eBook Store The Pragmatic Bookshelf Convolutional neural network Rational Unified Process UML 統一モデリング言語 Plantuml レガシーコード改善ガイド Add Code from a Template | Android Studio Protocol Buffers Amazon Athena Sumo Logic Splunk jq Becky! Internet Mail Wanderlust リファクタリング　既存のコードを安全に改善する CODE COMPLETE 第2版上 Error handling and Go Thinking in React - React Design Patterns Martin Fowler UNIXという考え方―その設計思想と哲学 Takuto Wada: "若者への課題図書としてまずは『達人プログラマー』と『UNIXという考え方』を挙げた" 新卒ソフトウェアエンジニアのための技術書100冊 - クックパッド開発者ブログ The Best Software Writing I: Selected and Introduced by Joel Spolsky steps to phantasien

amazon thinking blog e3 error wanderlust generated splunk unix neural networks a6 design patterns uml 8b e3 martin fowler 5etfw sumo logic andrew hunt joel spolsky pragmatic bookshelf convolutional amazon athena protocol buffers rational unified process

Ep027 – Brett Adam (Managing Director – Zendesk) on creating pills vs vitamins

The Startup Playbook Podcast

Play Episode Listen Later Nov 29, 2016 55:58

In episode 27 of The StartupPlaybook Podcast we did a live podcast interview with Brett Adam, the Managing Director Australia & New Zealand and VP of Engineering at Zendesk. Brett has had more than 25 years experience in the software industry, with a background that includes CEO and CTO level positions in both public and private companies, software architecture and engineering, product management, marketing, sales and corporate development. He has a wealth of experience in growing and running large organisations and in his current role he is responsible for the Zendesk Melbourne office, with a mission to strengthen Zendesk's presence in the region and support the local team in all things. In the interview Brett shares why startups should look to bootstrap their business, getting validation from the mainstream market, the importance of investing in relationships and Navigating the different stages of growth. Show Notes: Zendesk (website) Crossing the chasm - Geoffrey Moore (book) Finding great developers - Joel Spolsky (blog) Purple Lion (Not for profit) Brett Adam (Twitter) Brett Adam (LinkedIn) Brett Adam (Email) Credits: Intro music credit to Bensound Click here to listen on iTunes Click here to listen on Stitcher The post Ep027 – Brett Adam (Managing Director – Zendesk) on creating pills vs vitamins appeared first on Startup Playbook.

ceo navigating new zealand managing directors engineering stitcher crossing cto vitamins credits pills bensound zendesk geoffrey moore joel spolsky startup playbook

218: A Spark of Inspiration

Giant Robots Smashing Into Other Giant Robots

Play Episode Listen Later Nov 20, 2016 35:37

On Drip, Derrick launches a free tier, and utilizes credit card anti-fraud measures. Ben publicly launches FormLinter, pauses exploring new product ideas in favor of giving attention to existing ones, and starts to rebuild the product team. They also discuss the merits of remote vs in-person collaboration, the pros and cons of open offices, and dealing with interruptions from notifications and meetings. Upcase FormKeep Drip Stripe: Radar Caffeine Effects on Sleep Study The Development Abstraction Layer- Joel Spolsky Announcing FormLinter

inspiration spark drip sleep study joel spolsky upcase

Rewrite! | David Heinemeier Hansson | Business Of Software Conference USA 2015

united states business co founders creator software rewrite basecamp ruby on rails conference usa david heinemeier hansson joel spolsky

Play Episode Listen Later Jul 13, 2016 69:05

What's number one on Joel Spolsky's list of ‘Things You Should Never Do'? “Rewrite your software from scratch.“ David Heinemeier Hansson disagrees. In this talk, ‘Rewrite!‘ at Business of Software Conference USA 2015, David Heinemeier Hansson, Co-Founder, Basecamp, and Creator of Ruby on Rails explains why he disagrees and discusses his experience in rewriting the code for Basecamp, not once, but twice, with the third version of Basecamp launched this month. --- Send in a voice message: https://anchor.fm/business-of-software/message

58: Nobody Gets Fired For Buying IBM

The Bike Shed

Play Episode Listen Later Apr 6, 2016 45:36

Should you rewrite or refactor? What should you consider as you weigh this decision and what exactly constitutes a rewrite anyway? Things You Should Never Do, Part I - Joel Spolsky on Software Rewrites What does the phrase "Nobody ever got fired for choosing IBM" mean? When Understanding Means Rewriting by Jeff Atwood The Big Rewrite, revisited by DHH Thank you to Hired for sponsoring this episode!

fired ibm hired dhh jeff atwood joel spolsky

51: Is Sim City Running? (Steve Klabnik)

The Bike Shed

Play Episode Listen Later Feb 10, 2016 43:56

We enjoy a wide-ranging discussion with Steve Klabnik on the importance of good documentation, the sometimes cloudy definition of a breaking change, the politics of open source contributions, and work/life balance or boundaries. Steve Klabnik - twitter, website, blog Let's Talk About Ecosystem Documentation SimCity Mode in Windows 3.1 from Joel Spolsky Rescuing Resque… Again Netrunner IntermezzOS Writing an OS in Rust by Philipp Oppermann Bors - an automated integrator for GitHub High Five - a bot that encourages good contributions

running writing os windows rust github high five simcity netrunner bors joel spolsky steve klabnik intermezzos

Episode 186: 「越来越不觉得 2016 年是虚拟现实元年了。」

IT 公论

Play Episode Listen Later Jan 10, 2016 94:59

章节（时:分:秒）： 00:00:00 开场。《IT 公论》会员计划 00:01:28 听众反馈 00:06:42 互联网技术圈耻辱柱 00:12:35 快播庭审 00:22:13 反恐法 00:31:03 联想在 CES 2016 发布的一些新产品 00:37:12 Smartisan T2 01:02:02 Netflix 全球扩张 01:10:33 平板电子杂志的衰亡 01:16:35 Oculus Rift 开始接受预订 01:34:10 尾声本期会员通讯将于稍后发至各位会员邮箱。每月三十元，支持不鸟万如一和 Rio 把《IT 公论》做成最好的科技播客。请访问 itgonglun.com/member。若您无意入会，但喜欢某一期节目，也欢迎用支付宝或 PayPal 支付小费至 hi@itgonglun.com，支付宝用户亦可扫描下方二维码：我们推荐您使用泛用型播客客户端订阅收听《IT 公论》，但您也可以在喜马拉雅、荔枝 FM 或网易云音乐收听。相关链接《IT 公论》博客 IPN 播客网络 Telegram 听众群列表关于 Edward Tufte 的读音六公司关于抵制流量劫持等违法行为的联合声明 Smartisan T2 关于 Mac 团队早期历史的 Folklore.org Criterion Collection Joel on Software Joel Spolsky Maciej Cegłowski Pinboard Plurk 关于美国国家杂志大奖取消「平板杂志」类别的文章美国杂志发行公信会 General Magic IPN 播客网络常见问题解答人物简介不鸟万如一：字节社创始人 Rio: Apple4us 程序员

netflix software mac rio alliance paypal ces folklore qr codes oculus rift criterion collection ipn general magic pinboard joel spolsky edward tufte plurk maciej ceg

a16z Podcast: The Future of Software Development

a16z

Play Episode Listen Later Jan 5, 2016 32:47

As software becomes core to every industry, there is a need for more and more software development across practically every department in a company. But as anyone who has tried to get quality software developed knows, that has given rise to a supply and demand problem. Leveraging open source software is a big part of the solution to that problem, but venturing into the open source world raises all sorts of questions for most companies. For example, how do you engage as a company in the open source community; what are your obligations to the project; and if you are hiring a development team what clues ought you to be looking for to get the best developers? And what are the developers looking for? And in the end, who's responsible and accountable for the all this code flowing around? In a discussion from the firm's 2015 Tech Summit, Steven Sinofsky digs into all those questions with a panel that includes Roger Dickey, founder and CEO of Gigster, Slack CMO Bill Macaitis, GitHub Director of Field Services Matthew McCullough, and Joel Spolsky, co-founder and CEO of StackOverflow. The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments and certain publicly traded cryptocurrencies/ digital assets for which the issuer has not provided permission for a16z to disclose publicly) is available at https://a16z.com/investments/. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

ceo development leveraging references charts open source coding software development andreessen horowitz stack overflow a16z tech summit joel spolsky gigster steven sinofsky roger dickey

We.Developers 040 – Como ser desarrollador (y no morir en el intento)

We.Developers

Play Episode Listen Later Sep 3, 2015 124:25

Partiendo de la excelente serie de artículos “Fraudismo 101” de Diego Freniche, repasamos con el propio Diego muchas de las características particulares de esta nuestra profesión: situaciones, filias, fobias y manias varias que pensamos son propias, pero que cuando compartimos, nos damos cuenta de que las sufrimos todos. Únete a nosotros en este viaje a [...]

developers swift java morir como ser intento partiendo desarrollador erlang joel spolsky

94: Don't Be Clever

Embedded

Play Episode Listen Later Mar 25, 2015 89:57

The linker post for this episode is Be Excellent to Each Other. Dennis Jackson spoke with us about drones (and Airware), simple code, and learning. Hobbyist drones and UAVs on Amazon: tiny and cheap, medium (Christopher's gift), andplease-I'm-drooling-right-now. Only the last one may be an Airware platform (Dennis could neither confirm nor deny). Airware's breakdown of proposed FAA rules Simple code: Cyclomatic complexity Chris Svec's episode on empathy driven design (he'll also be at ESC Boston!) Test Driven Development for Embedded C by James Grenning Don't Make Me Think: A Common Sense Approach to Web Usability Dennis has also worked on DEKA's iBOT and at Avinger's OCT system. Dennis had a list of suggested articles and blogs on safety critical software development: 30 Pitfalls for Real Time Systems (part 1 and part 2) Rules for defensive C programming Joel Spolsky's blog (see top 10) Why are you still using C The Power of Ten -- 10 Rules for Writing Safety Critical Code Dennis' other suggested reading (ongoing blogs): Coding Horror Jason Sach's Embedded Systems The Old New Thing Rands in Repose (management and leadership)

amazon simple software engineering pitfalls clever each other repose uavs hobbyist test driven development dennis' joel spolsky be excellent dennis jackson airware chris svec

Kodsnack 53 - Gör en Python 5

Kodsnack

Play Episode Listen Later Jun 3, 2014 52:28

Kodsnack 53 - Gör en Python 5 Kristoffer börjar berätta för Fredrik om sina öden och äventyr på svenska Pycon och tar med oss på en resa från datainsamling och bearbetning via kryptomysterier till Python 2 mot Python 3 och problemen med stora omstarter mellan versioner av mjukvara. Python 3 har stora problem med att vara något nytt och annorlunda som skiljer sig så mycket att den stora massan inte har anledning att byta till det. Samtidigt har utvecklarna av språket gått vidare så att ingen gör något alls med det språk folk faktiskt använder. Det finns en risk att man tappar det som gjorde ens skapelse värd att använda när man skriver om den för att bli modernare, mer generell eller vad man nu föresatt sig att göra. Avsnittet sponsras av Cenito. Länkar Pycon.se Fredrik Håård - huvudarrangören av Pycon.se Pycon internationellt Europython Mali Boko haram Bahnhofs datahall - tidigare civilförsvarsledningsplats - under Vita bergen i Stockholm Helena Bengtsson JOIN i databaser - kombinerar poster från flera tabeller Perl Fax OCR - optical character recognition Beautiful soup - pythonbibliotek för att få ut data ur webbsidor och annan mer eller mindre ostrukturerad data Kodsnack 5 - Kanelbullens dag nämnde också Beautiful soup Laurens Van Houtven Rackspace - sysslar med moln och hosting och anställer Laurens Kryptografi Engångsskiffer - teoretiskt perfekt kryptering med problem i verkligheten Diffie-Hellman key exchange Man-in-the-middle-attack Python 2 och Python 3 PyPI - Python package index och pip - ett program för att installera paket Pythons historia Unicode ASCII Indexera över en sträng, i Python 2 och i Python 3 Kenneth Reitz Requests - modul för HTTP i Python, som Kenneth skrivit Perl 6 - den ännu inte släppta versionen av Perl Generatorer - funktioner som genererar data Go - ett språk vi talat om förr Joel Spolsky om Netscapes omskrivning och att skriva om i allmänhet Winamp It really whips the llama's ass Winamp3 Det tycks fortfarande finnas lite liv i Winamp AOL - som var stora förr i tiden Dotcomkraschen Guido van Rossum Kärnutvecklare av Python 3 Python 2.7 blir den sista av Python 2 HTML 5 XHTML XSLT - språk för att omvandla XML-dokument till andra XML-dokument HTTP 2.0 SPDY - Googles nätverksprotokoll som är basen för HTTP 2.0 HTTP/2 considerations and tradeoffs - lång redogörelse med gott om länkar

google man python html avsnittet fredrik samtidigt kristoffer xml pythons pypi pycon bahnhofs fredrik h joel spolsky diffie hellman spdy kanelbullens kodsnack

239: TZ Discussion - Putting Up Drywall at the New McDonalds

techzing tech podcast

Play Episode Listen Later Jul 29, 2013 89:45

Justin and Jason discuss the canvas-based drawing app that Justin built for Digedu using his JS library known as $$, how Jason got drag and drop working in Titanium and his idea for creating a mobile game for learning electronics, the original Star Trek series vs. Start Trek: The New Generation, the single window strategy for building mobile apps, creating 180 websites in 180 days, the challenge of staying current with the latest programming technologies, the 97-year old man who makes art using MS Paint, how PayPal accidentally credited a man $92 quadrillion, coding vs managing coders, the selling of Pluggio, whether Jason's secret project will remain secret forever and his future plans for Catalyst, why men need women and why they become more generous when they have daughters, why you can't force kids to be what they're not, Jason's experiment with a low-carb diet, the Soylent production delay, Justin's intuitive eating / habit-building plan, Greenwald's drip news strategy for keeping the NSA story alive and how Nancy Pelosi saved the NSA surveillance program, the television show Breaking Bad (don't worry - no spoilers), what's killing the bees, how Joel Spolsky killed a software patent in only 10-minutes using AskPatents.com, Xamarin - an IDE and platform for creating native, cross-platform desktop and mobile apps using C#, and a new theory of cancer postulated by physicists.

putting star trek paypal mcdonalds paint nancy pelosi breaking bad catalyst nsa ide js titanium greenwald soylent drywall xamarin joel spolsky

Stack Exchange Podcast - Episode #33 - It's Back

stack exchange joel spolsky

Play Episode Listen Later Oct 15, 2012 52:33

We're back baby! After a 7 month hiatus, the Stack Exchange Podcast is back with new co-hosts: Joel Spolsky and Jay Hanlon. Our guest this week: David Fullerton

Stack Exchange Podcast - Episode #33 - It's Back

stack exchange joel spolsky

Play Episode Listen Later Oct 15, 2012 52:33

We're back baby! After a 7 month hiatus, the Stack Exchange Podcast is back with new co-hosts: Joel Spolsky and Jay Hanlon. Our guest this week: David Fullerton

113: TZ Interview - Jeff Atwood / Stack Exchange

techzing tech podcast

Play Episode Listen Later Mar 16, 2011 86:38

Justin and Jason interview Jeff Atwood, co-founder of Stack Overflow and the Stack Exchange network, about how he got started as a coder and his passion for programming and mentoring, how he and Joel Spolsky came up with the idea for Stack Overflow, his belief in free software and the Open ID initiative, the process of raising venture capital for Stack Exchange and his views of entrepreneurship, why he and Joel stopped doing the Stack Overflow podcast and whether they might start up again, and the hardest step when scaling a web app.

stack overflow stack exchange openid jeff atwood joel spolsky

TMTC 25 – Eric Malamisura from AgileDash

Devchat.tv Master Feed

Play Episode Listen Later Jun 22, 2010 45:11

Eric has his own company at elucidsoft.com. He's a freelancer and is developing a new product called Agile Dash. Eric is bootstrapping his company. Some of his inspiration comes from Peldi from Balsamiq Mockups and Joel Spolsky. Eric does his prospecting through LinkedIn, Facebook, and Twitter for his freelance business. Here are some books recommended in this episode (affiliate links): On Business: Rework Freakonomics: A Rogue Economist Explores the Hidden Side of Everything (P.S.) Influence: The Psychology of Persuasion (Collins Business Essentials) Crossing the Chasm Anything by Guy Kawasaki Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition On Programming: Code Complete: A Practical Handbook of Software Construction Working Effectively with Legacy Code Design Patterns: Elements of Reusable Object-Oriented Software Download this Episode

crossing rework chasm creativeasin guy kawasaki influence the psychology hidden side 3d1 legacy code working effectively joel spolsky web usability peldi creativeasin 006124189x

The Podcast about Podcasts with Joel Spolsky

podcasts stack overflow leo laporte joel spolsky

Play Episode Listen Later Apr 22, 2010 47:03

The worst show ever? Perhaps, but it's Meta! It's Joel Spolsky this week, the other half of the StackOverflow Podcast, chatting with Scott this week about podcasting. How does Joel record shows? How does Scott? Is this the end of the StackOverflow show? How does Leo Laporte manage? Should we visit his house? All this, plus sour grapes.

Hanselminutes on 9 - Spolsky, Atwood, Blyth, Hanselman = Crazy-Delicious || Content-Free?

Hanselminutes On 9 (HD) - Channel 9

Play Episode Listen Later Oct 23, 2009 68:22

I spoke at the StackOverflow conference in San Francisco and Seattle this week (long week, let me tell you) and I got the opportunity to sit down with Jeff Atwood from CodingHorror and Joel Spolsky from Joel on Software, along with the man, the legend, Rory Blyth. The audio also appeared on the StackOverflow podcast in part, but here's the raw video from our backstage ramblings.Warning: extreme ramblosity ahead!Joel explains his Duct Tape Programmer post. Apparently DevDays is a duct tape conference, and this section of the recording is a duct tape podcast. Some discussion of the ubiquity of mobile code. Also, if you are nostalgic for the era “when development was hard”, the consensus is that you should be doing mobile development today on iPhone, Android, Windows Mobile, or Symbian. Rory elaborates on his experience with (and effusive opinions on) iPhone development to date. Is coding in Objective-C best accompanied by a flux capacitor, New Coke, and Max Headroom? Also, his excitement for MonoTouch. Joel and Scott put on their amateur language designer hats and have a spirited discussion of type inference and Fog Creek’s in-house DSL, Wasabi. Scott covers some of the highlights of new and shiny features coming in the Visual Studio 2010 IDE, the C# 4.0 language, and the ASP.NET MVC 2.0 web framework.

san francisco seattle iphone software android delicious ide wasabi atwood asp stack overflow new coke dsl visual studio blyth objective c windows mobile symbian jeff atwood joel spolsky hanselman spolsky hanselminutes fog creek monotouch

Visiting Fog Creek Software and Joel Spolsky

Play Episode Listen Later Apr 14, 2009 44:16

Scott's in New York this week and he stops by the Fog Creek Software offices on Broadway and chats with Joel Spolsky. Why did they write their own compiler? How long have they used VBScript? What does Joel think about online community? All this and less in this episode!

new york broadway visiting joel spolsky fog creek software

VV Show #56 – Joel Spolsky of Fog Creek Software

FalaFreela - Carreirasolo.org

Play Episode Listen Later Apr 13, 2009

Joel Spolsky first came on Venture Voice over three years ago to discuss his company which he launched in a very different way from most entrepreneurs. Rather than start with the big idea and pay lip service to building a great team, Joel focused on getting great programmers first.…

business technology entrepreneur entrepreneurship startups capital vc venture joel spolsky fog creek software venture voice

FalaFreela#16 - Teriam os programadores o DNA freelancer?

Pensadores Criativos

Play Episode Listen Later Dec 15, 2008 53:52

E fechamos o primeiro ciclo de episódios dedicados às profissões freelancers. Ouvimos músicos, ilustradores, redatores e, claro, programadores para dar as dicas básicas para quem já está ou quer entrar para a vida daqueles que são uma empresa de um homem só.No episódio de hoje Mauro Amaral, Humberto Oliveira, Carolina Vigna-Marú & Rafael Apocalypse apresentam características, definições e dicas sobre a arte e técnica por trás dos códigos de programação. É verdade que programadores têm sempre jobs à sua espera? Que seu lado metódico os ajuda serem mais bem sucedidos na vida de freela? Meninas têm espaço nesse mercado? Dicas, truques e macetes em mais um episódio da 1/2 hora mais valiosa do seu dia.Para ajudar você neste episódio, falamos de:Joel Spolsky, ex-funcionário da Microsoft e que agora tem sua própria start-upBlogblogs, o códex da blogosfera brasileiraMetodologias de trabalho para programadores na Wikipedia: Scrum e XPCodeIgniter, a framework em PHP que o Rafael utiliza nos seus projetosASP.Net, a frameword da Microsoft que o Humberto usa na maior parte do tempo

microsoft freelancers dicas php humberto meninas ouvimos o dna joel spolsky mauro amaral

FalaFreela#16 - Teriam os programadores o DNA freelancer?

Play Episode Listen Later Dec 14, 2008 53:52

E fechamos o primeiro ciclo de episódios dedicados às profissões freelancers. Ouvimos músicos, ilustradores, redatores e, claro, programadores para dar as dicas básicas para quem já está ou quer entrar para a vida daqueles que são uma empresa de um homem só. No episódio de hoje Mauro Amaral, Humberto Oliveira, Carolina Vigna-Marú & Rafael Apocalypse apresentam características, definições e dicas sobre a arte e técnica por trás dos códigos de programação. É verdade que programadores têm sempre jobs à sua espera? Que seu lado metódico os ajuda serem mais bem sucedidos na vida de freela? Meninas têm espaço nesse mercado? Dicas, truques e macetes em mais um episódio da 1/2 hora mais valiosa do seu dia. Para ajudar você neste episódio, falamos de: Joel Spolsky, ex-funcionário da Microsoft e que agora tem sua própria start-up Blogblogs, o códex da blogosfera brasileira Metodologias de trabalho para programadores na Wikipedia: Scrum e XP CodeIgniter, a framework em PHP que o Rafael utiliza nos seus projetos ASP.Net, a frameword da Microsoft que o Humberto usa na maior parte do tempo

marketing design microsoft wikipedia freelancers dicas scrum php xp humberto asp meninas ouvimos o dna metodologias joel spolsky codeigniter mauro amaral

Podcast, recorded Friday, November 14, 2008

Talking About Stuff

Play Episode Listen Later Nov 15, 2008

The TalkThe Stuff:Clay ShirkyHis book, Here Comes Everybody: The Power of Organizing Without OrganizationsHis presentationiPhone app to copy files from your computer to your iPhone, without needing to connect through iTunesThe Amazon KindleHere Comes Everybody (Kindle edition)iPhoneLeo LaporteHis podcast networkThe MacBreak Weekly podcastThe This Week in Tech podcastJohn DvorakAdam CurryThe No Agenda podcastJoel SpolskyJeff AtwoodStack OverflowThe Stack Overflow podcastreMovemConfessions of an Economic Hitman (audio edition)Angler (audio edition)The Way of the World (audio edition)The Planet Money podcast60 Minutes piece on credit default swapsThis American Life episode describing credit default swapsHardball with Chris Matthews

amazon world internet technology media politics talk books news podcasts digital tech iphone confessions tesla economy kindle audiobooks automotive this american life motors amazon kindle angler stack overflow hardball chris matthews planet money webobjects mzstore adam curry no agenda leo laporte economic hit man this week in tech podcast recorded jeff atwood joel spolsky clay shirky macbreak weekly radio episode here comes everybody viewsoftware john dvorak organizing without organizations here comes everybody the power

StackOverflow uses ASP.NET MVC - Jeff Atwood and his technical team

technical asp stack overflow jeff atwood asp.net joel spolsky

Play Episode Listen Later Oct 16, 2008 49:34

Scott chats with Jeff Atwood of CodingHorror.com and most recently, StackOverflow.com. Jeff and Joel Spolsky and their technical team have created a new class of application using ASP.NET MVC. What works, what doesn't, and how did it all go down?

Customer Support - an Interview with Joel Spolsky

UXpod - User Experience Podcast

Play Episode Listen Later Mar 30, 2007 23:10

What makes good customer service?Joel talks about fixing everything two ways, not outsourcing technical support, taking the blame, and about the puppet.Check out Joel's blog (http://www.joelonsoftware.com) I mention the Irish Guitar Podcast (http://www.irishguitarpod.com)Daniel Szuc and I wrote The Usability Kit (http://www.theusabilitykit.com).Duration: 23:10File size: 10.6MB

customer support 6mb joel spolsky

VV Show #25 – Jason Fried and Joel Spolsky Win Venture Voice Entrepreneurial Achievement Awards

Play Episode Listen Later Jan 25, 2006

The listeners have spoken. Jason Fried of 37signals and Joel Spolsky of Fog Creek Software have won Venture Voice Entrepreneurial Achievement Awards. They came in second and third place out of a pack of over 20 world-class entrepreneurs we’ve interviewed on the show (we’ll announce the Venture Voice Entrepreneur of the Year Award winner next week).…

business technology entrepreneur entrepreneurship startups capital vc entrepreneurial venture jason fried achievement awards joel spolsky fog creek software venture voice

VV Show #25 - Jason Fried and Joel Spolsky Win Venture Voice Entrepreneurial Achievement Awards

Play Episode Listen Later Jan 24, 2006

Download the MP3. The listeners have spoken. Jason Fried of 37signals and Joel Spolsky of Fog Creek Software have won Venture Voice Entrepreneurial Achievement Awards. They came in second and third place out of a pack of over 20 world-class entrepreneurs we’ve interviewed on the show (we’ll announce the Venture Voice Entrepreneur of the Year Award winner next week). It was a close race and you gave us some really impassioned votes. In this show, Jason and Joel give us some hints about what their companies are launching this year. They don’t get to have all the fun -- we play some of your comments too.

business technology entrepreneur entrepreneurship table startups capital vc entrepreneurial venture td jason fried achievement awards joel spolsky fog creek software venture voice 2mjpeyqxbvi

VV Show #20 – Joel Spolsky of Fog Creek Software

Play Episode Listen Later Nov 22, 2005

While some entrepreneurs fret over new business ideas, Joel Spolsky of Fog Creek Software focuses on hiring the best and brightest for his New York City-based software company, and then figures out how to make a profit with the products they create.…

new york city business technology entrepreneur entrepreneurship startups capital vc venture joel spolsky fog creek software

VV Show #20 - Joel Spolsky of Fog Creek Software