The Changelog: Software Development, Open Source - Practical ways to solve hard problems (Interview)

Episode Date: April 22, 2022

Frank Krueger joined us to talk about solving hard problems. Earlier this year he wrote a blog post titled "Practical Guide to Solving Hard Problems," and a lot of what he had to say really resonated with us. The premise is simple — if you have to write some code that you’re just not sure how to write...what do you do? What are the practical steps that you can take when you’re feeling stumped? Today’s show goes deep on that subject...practical ways to solve hard problems and ship your best work. Frank has his own podcast called Merge Conflict — check it out at mergeconflict.fm.

Welcome back. This is The Change Law. Thank you for tuning in. If you're new to the pod, head to changelaw.fm for all the ways to subscribe. If you're a longtime listener, thanks for coming back. Hey, we appreciate you. Check out our membership at changelaw.com slash plus plus. Directly support us, make the ads disappear, and get access to bonus content.

Today, we're talking with Frank Krueger about solving hard problems. Earlier this year, he wrote a blog post titled Practical Guide to Solving Hard Problems, and a lot of what he had to say really resonated with Jared and I. The premise is simple. If you have to write code, but you're just not sure how to write, what do you do? What are the practical steps that you take when you're feeling stumped? And today's show goes deep on that subject, practical ways to solve our problems and ship your best work. By the way, Frank also has his own podcast. It's called Merge Conflict. Make sure you check it out at mergeconflict.fm.

And big thanks to our friends and partners at Fastly for keeping our podcast super fast globally. Check them out at fastly.com. This episode is brought to you by Sentry. Build better software, faster, diagnose, fix, and optimize the performance of your code. More than a million developers and 68,000 organizations. They already use Sentry, and that includes us. Here's the easiest way to try Sentry. Head to sentry.io slash demo slash sandbox. That is a fully functional version of Sentry you can poke at. Best of all, our listeners get the team plan for free for three months. Head to sentry.io and use the code changelog when you sign up.

Again, sentry.io and use the code changelog. So we have Frank Kruger with us to talk about his practical guide to solving hard problems. Frank, welcome to The Change Log. Yo, yo. Thank you for having me. Appreciate it to be here. Thank you. We're happy to have you as well. This is a really cool post.

And like you say in the post, not nothing groundbreaking, no huge revelations, but just like sometimes these are good things to write down, good things to think about from someone who's been through hard problems for a long time,

been programming a long time. Give us a little bit of your backstory, your history, so we know where you're coming from that brought you to a place where you can write this down and have so many of us nod our heads along

as we read with you. I think the hard problems are the only ones that are interesting to solve, right? The only ones that kind of keep your heart pumping and keep you kind of in this business. Otherwise, it's easy to burn out. Right. But, hi, I've been programming for a while now. I guess since I was 16, I got my first professional gig working at an R&D shop at General Motors. Got out of high school for half the time

and I got to go work in an R&D lab and program embedded systems in assembly and C. It was fun. But I was also a bit of a self-taught programmer, so hacked video games. Eventually got a job at Microsoft, worked on Windows Vista, the best operating system ever released. Oh, yes. That's my favorite one. Can you still admit it? Oh, God. You know, at this point, I'm proud of it. Like, I think it's one of those, if it doesn't kill you,

it makes you stronger kind of things. I learned so much working on it. Everyone needs to work on a giant, I'm not going to call it a failure. It was released. It was fine, but not success. It's humbling. Yeah.

What part of Vista did you work on? I was actually a dev in test. success. It's humbling. What part of Vista did you work on? I was actually a dev in test, so I was responsible for making sure that codecs like JIF and JPEG and TIFF would not crash the machine. If you remember those days, Microsoft would be on Slashdot a lot for a new vulnerability found in JIF. Just download this image and we can hacks for your system right it would like give you straight like admin privileges from like zero to admin privileges with one animated yeah exactly yes i showed up at microsoft when security was becoming a really important thing and we were

cracking down on everything and we were just beating these apis to death but i also worked on designing uh the imaging apis for what became WPF, the C-sharp managed way to write Windows apps. It's a UI framework. And so I worked on that. So good stuff came out of Vista. Honestly, we're using a lot of fundamental Vista technologies on Windows even today. It was a rough release.

To give you some credit, though, the hard problem about, I think, Windows generally was the upgrade path. There was obviously some flaws in the operating system as the new versions come out, but the upgrade path seemed to be the biggest hurdle for Microsoft to finally, and I'm not even sure if they finally conquered it, because I've since bailed on the operating system, got mad respect for it. Lots of users, a massive base. But the upgrade path was truly the challenge, not just simply the operating system as itself, like the new advancements in the tech.

Yeah, especially we were trying to push the GPU. And the GPU wasn't even that old at this point. But we said Mac was running on the GPU, so we should be running on the GPU. It was doing its compositing on the GPU. And so there was this big move of they want to increase the specs for that. And honestly, it takes a bit of bravery to move an operating system up a spec level like that. Say now we're going to require this class of GPU.

I don't think that that was a wrong decision necessarily. Windows had to get updated like that. And reverse compatibility or backwards compatibility just unfortunately is the victim there. Well, what a hard job it must be, though, to command the direction of an operating system used by not just millions, but like millions of millions. You know, like that's a high stakes game. You've got business class customers. You've got, you know, the direction of Intel, for example, or the PC in general. You can put it on pretty much anything, right?

Like a Mac is designed to be on a particular system, so there's a lot less of an issue with the footprint in terms of what you would hit and would it work, whereas the PC landscape, it's no man's land. It's every man's land. Yeah, I guess that's a better case. Every man's land. It's every man's land. Yeah, I guess that's a better case. Every man's land. That's it.

There's just so many GPUs. That was the hot topic at the time. To the point where long into the project, I would still boot up the operating system some days and the monitor would be flipped vertically and everything would be upside down. And you're just like, oh, it's one of those builds. And so you would have to use the computer upside down

to go download a new build and update your system and hope that the new latest build doesn't have the upside down bug today. So would you flip the monitor or would you stand on your head? What was the move? You just learn how to reverse it in your head. It's amazing what the brain can accommodate. You learn. You know, the first time it's hard the second time it's

harder the third time you get used to it yeah you could actually turn it around and have a mirror on the wall and you know what i mean you could have mirrored it literally with a mirror yeah but i guess no it's upside down you can have concave you'd have to concave get a concave mirror then too in that case to to you out. Well, whatever. Some monitors had a flip option. So if you're really desperate, you could go into the monitor settings and reflip it. Wow. So you learn a lot on that kind of project.

Totally. So Adam said he bailed on Windows. I also bailed on Windows. It sounds like you also bailed on Windows because you're like an iOS guy now, right? You've been doing iOS development. Take us on the next part of your path. Well, after that wonderful Windows Vista experience, I bought a Mac and I decided... Haven't looked back.

That's not actually true. In the proper timeline, I started my own company. Some friends were needing help getting contract jobs. There was a lot of immigration and people taking advantage of contract employees for a long time. And so I started a contracting business to help out a lot of my friends that were working on Visa. And at the same time, I also became a military contractor and worked on control systems for cruisers for the Indian Navy. And spent quite a few years just doing embedded system development for militaries.

That was another big learning experience. So basically I wanted out of the PC world. Yeah, you went real far upstream. So what were your learnings there? When I hear that, I like large contracts slow progress bureaucracy like what was it like in reality yeah uh yeah don't forget bribery and all that stuff too um well let's just say it opens your eyes to how the world works when you see how the military works then you're really seeing how the world works. But no, what I learned from a software perspective was reliability.

So we would constantly talk about hot-swappable, cold-swappable. I had software, its only job was to control the rudder of the ship. You turn the wheel right, the rudder should go right. You turn the wheel left, the rudder should go left. It's the easiest program to write in the entire world. But the program still ended up being 100,000 lines of code because there are somewhere around 500 error conditions because the software has to run on five different locations on the ship

running in parallel on two identical copies in each location. If a part of the ship gets destroyed, the network has to recompensate. At all these different levels, there are command security levels, there are alarmings to do, manual control overrides, all that stuff. So what I learned was how to write reliable software. And I even want to rephrase it. It started my journey on how to learn how to write reliable software. Because there's nothing like having people's lives in your hands and you haven't proved that your software is correct yeah it's like having a very simple game like pong or something or like where there's the controls are like left right up and down like a 2d game but then it's on like expert mode where like any

little mistake and you immediately die and have to start over yeah because like you said i mean all those error modes and then redundancy too, right? It has to run in multiple places at the same time. Sounds like hard problems. I was also designing user interfaces that became hardware panels. So I would draw up a hardware panel

with all these buttons and these displays. I would have to help manufacturing actually build the panel. I'd help them wire the panel, connect that into all the software because back then you didn't use touchscreens you used giant panels of arrays of buttons and so I was also building all those panels so a lot of just how do you guarantee

that you're even talking to the user interface correctly there's those kind of tiny details you don't think about when you're writing an iOS app, for instance. Yeah, it makes you take iteration for granted when you don't have to have that circumstance. Like if you're designing a hardware panel that has to go off to be manufactured, you got to get that design right before you send that design off, right? You can't say, well, we'll just ship this. And as soon as we start using it, we'll know where it fails. Because once you're using it, it's done. It's like set in stone, basically, right? Yeah. I remember one time I was presenting

the system to a submarine commander. He was just a part of an entourage that was just giving a demo. And he looked at me and says, why is this thing so complicated? And I had to laugh because I just turned around because I had it sitting right next there was the book of error codes that was not written by me. It was written by all the admirals in there, you know, whatever. And I just handed him the book of error codes. I'm like, that's why. 500 error codes. Why is this so complicated?

You threw the book at him. Oh, yeah, I guess. I didn't throw it. He was quite intimidating. Yeah. What's the biggest learning you've learned from or continue to learn from when it comes to reliability? What are some of the cardinal sins or cardinal rules? You have to test the error path just as much as you test the functioning path. It's always an edge case in the error handling where you mess things up. It's so easy to write code that, you know, when it's working correctly, it works correctly.

That's the easiest code to write. What happens if this line fails? What happens if that line fails? What happens if the machinery fails? What if the connection fails? Handling all those error conditions. And the best way to do that is to just assume anything can error any time. And that sounds like a terrible way to program. But programming systems like Erlang have showed us the correct way to do that. And so I fell in love with isolated processes

that were expected to fail, and you just handle those failure conditions. Every message pass, every function call can fail, and you better have a good smart plan for how to handle that. So to answer your question in general, the answer is assume everything can fail and make sure that, you know, just in my own code, I'll just put random throw exception here

just to see what happens. Like while you're working, just to see what happens. It's like your own little chaos monkey, but inside your own local code base. That's a cool idea. Especially if you're trying to solve a hard problem that you really don't know how to work on. It's much more fun to pop up an error dialogue.

You're like, oh, that took down the whole process. I wasn't expecting that. Good way to procrastinate, right? Yeah, and it helps the overall quality because... Oh, for sure. Chances are, you know, software seems to fail. I keep trying to write. And I say this, I don't want you to think

that I write correct software because I have crash report after crash report on my apps. But you keep working at it, you chisel it away. Alright, so bring us from defense contractor to iOS developer. We just have to take a break from all that, right? It's just a little

bit too much. Burnt out. It's just a little bit too much. Go indie. Well, I already had my company, so already bit too much burnt out yeah this is a little bit too much go on indie yeah go indie well i already had my company so i'm already i don't have a job anymore so i'm one of those people uh and i decided i wanted to write software so actually i first tried to write uh like windows apps at first but there was not a great marketplace for that i was inspired by a macbook that i had just bought the iphone had just come out i was really inspired by that for my I had just bought. The iPhone had just come out.

I was really inspired by that. For my whole life, I'd wanted a smart computer in my pocket. And finally, there was a really good one. And that was awesome. I really wanted to program it, even though you couldn't. But it was all that just culminating into... I mean, I even wanted to program it so much. I wrote a DNS server that rerouted all the

YouTube calls so that you could watch your own videos using the YouTube app on the iPhone. I was just so desperate to write software for it. And the moment Apple had an SDK, I just jumped on top of it. Did you hop into the original concept, the really sweet solution, I think they called it, which was the web apps? I mean, did you try to do web apps initially? Because before the App Store, that was Apple's first, like, hey, you can program it with web apps. And it's kind of like, meh, meh, meh. But did you at least try that kind of stuff? So I skipped another little part of my career. I spent two years being a web developer after the military stuff. And that kind of burnt me out. I was like, I don't really want to do this html was

crushing my soul all of it was crushing my soul i was a native app developer i've been writing uis and vb since the 90s i like writing native apps i know how native app apis work i know how rendering and you know all that stuff it's just a more comfortable place for me gotcha and so plus um i i even question it to this day like should I become a web developer again but I think I just got so burnt out with just two years of being a web developer that I haven't wanted to do it again yeah if you couldn't last two years back then

you probably wouldn't last six months now because things are rapidly evolving and there's always a new target and there's a lot of power in the web in terms of freedom and expressiveness and permissionless to a certain degree-ness. But there's a lot that comes alongside it as well.

So if you've been building native UIs your whole life, you know, then... And the iPhone was so nicely constrained. They were all the same resolution, 320 by 480. No one had a different sized iPhone. They were slow. Your software couldn't do much, so you had to be a clever programmer. And I'm an engineer and I'm terrible at marketing and sales. And I really need to rely on a third party to be a publisher. And early successes in the store, in the app store, showed that you could actually make some money at it versus starting your own website, drawing people to your own website, doing sales that way. So are you designing, building, and selling your own apps on the store, or are you contracting for other companies and building their apps?

I've contracted with a company once and built one app, but I was reminded that I don't like having a boss, and so I tend to stick to I design an app, write it, and sell it. It's a good system. I'm basically only accountable to the people who purchase it and whether anyone purchases it. I can spend two years working on something that I think is awesome, release it, make $10 a month on it,

and get a nice splash of cold water in the face and remind, don't write what you want, write what other people want. Yeah. So have you been able to build a sustainable business inside the app store? Yeah, I have. Since I would say about 2010 is when I started making enough money where I could comfortably live on it. And I've been able to continue that up to whatever date this is these days.

Does time exist? I don't know. And sustainable is the right way to sustainable is the right. Always been my focus, too. So I love that you chose that word. I want to be doing this into my 80s, you know, if I'm lucky. Wow. Well, the good thing is that you're focused on your I guess you're self-aware enough to know what your strengths and weaknesses are, which is sort of half the battle when you pick your career or pick your path because you recognize that you're an engineer first and marketing and distribution is not your strong suit.

And to leverage a way to still get joy from your passion and your craft while also making an impact. I think that takes a bit of time sometimes to iterate towards like, okay, I should be doing this. You know what I mean? Like focusing on something where there's actually a store with distribution that brings people there and all you got to compete with at that point is, I guess, is value for the app. Like does the app actually solve the problem?

Not so much, hey, come find my app. And I guess there is a bit of a challenge for some indie mac app developers or ios developers they do have to market i mean it's not that you don't i'm sure you can make more if you marketed but it's not necessary if you have the right kind of distribution opportunities yeah it's tricky because all my marketing friends scream at me because i do basically zero marketing so what i rely on is this terrible test of you release the app and you see how many people bought it if a lot of people bought it on day one the app's probably gonna be do all right if no one bought it on day one then there is just not an existing market there

so you have to hire a marketer to create the demand instead of fulfilling an existing demand. I would much rather fulfill an existing demand, but I understand marketing's place is like, maybe you've never heard of this concept and you totally got to check it out. And so that's their job. Right. I mean, some of it is awareness.

Like there might be demand, but people just don't know that it exists. But then there's also like when you push something up a hill and it's heavy, and you're like, why am I continuing when I have this other ball that's rolling down this hill? Or at least there's an obvious demand. So I think that's smart. It puts a lot of pressure on your day one launch, though, doesn't it? You spend two years toiling, you put a thing out.

I mean, that's going to be a pretty stressful day or week. It's the worst. Also because day one. It's the worst. It because they want it's the worst i hate launching i hate shipping yeah yeah talk about real lessons learned uh what do they say like a painting's never finished you just stop working on it same thing of rest for an app okay so i i always say i know when i'm need to release an app when i hate it okay so that's when i know i've need to release an app when I hate it. Okay, so that's when I know I've gotten to the right mental place where this thing actually needs to be shipped now. But day one is also, there's a little fog of war.

I have a little bit of an online following, so I can always have a few sales on day one. What really matters is week two. You want to know where that number is going to be in week two. So day one is just fun party times, and all you're telling yourself is don't even think about any of this until week two let's see what the week two number is okay that's wise what's your batting average uh how many apps have you put out and then of those what percentage are like successes in terms of you're going to keep working on them or they still make money for you today?

Not good. It depends on which dimension you want to look at. Sorry for asking. At least he's honest. He could have been like, it's amazing. Well, let's be real. Luck is a huge part of this universe. I released an app that had no competitors in 2010 and it's created a niche for itself that exists in its own little universe and I've been lucky and I've been able to live off of that app but at the same and that's iCircuit

have I been able to recreate that success? No and so that's like that's the tricky part I have apps that do good like I could probably live off of those other ones if you take away one like my whole fear was I don't could probably live off of those other ones if you take away one. Like my whole fear was, I don't want to live off of one app because I'm just too neurotic to do that.

I need to have a portfolio of something else out there. But I haven't been able to recreate that kind of success on demand. I've had some, but then I want to say, I've had some like critical successes where a lot of people like my apps so they're well regarded in that way and that pleases me just as much

except I do need to pay rent and survive in Seattle. It's not a cheap city. Right. Well I definitely hope you continue to have success on the app store. I think it's still something to be proud of. There's a lot of people that go through life and never have a success on the app store.

You think of musicians and you have the one-hit wonders. And it's like, hey, people make fun of a one-hit wonder, but it's like most of us are zero-hit wonders. That's actually pretty stinking good. And the fact that you can live off it and continue to do what you love and to continue to step up to bat, step up to the plate and see if you can hit another one yeah uh is admirable and you know very respectable so appreciate your

honesty but nothing to be ashamed of you definitely had done well no i i just wanted to make it clear like there's always a winner yeah it's it's not easy it's a tough world i used to do a lot of speaking at conferences and people would ask like oh i want to get into app development what's your advice and my advice is i lost money for the two first two years so have a lot of money in the bank before you even attempt to do this yeah it's hard to find that market but the actual good advice is pick your markets uh find an existing demand pick a market that has a lot of money and where there's not much competition that's a sweet spot work in that space then you can actually make a living off of it you don't make a game your game's not going

to be successful it doesn't even matter how good it is you're not going to make any money off of it too much competition yeah that's even when the when the store was small life was definitely easier but finding something on this on the store just from natural search, it only accounts for 20% of your sales, my sales. It's not a lot. Where's the other 80% come from then? Word of mouth, links, like my app has been used in universities now, so it's a part of some curriculums. That always helps, right? Become a part of a curriculum.

Sales security. Yeah yeah things like that um a lot of google searching you know good thing about a older app is you have better seo than a newer app new apps are tough new apps hire hire someone to do the marketing if you can afford it you spend a lot of your time on iCircuit or is your time kind of divided now considering your other apps that you might be running? It's still because I rely on it so much. I still put a fair amount of time into it to maintain it, make sure it's running good, make sure the reviews are still good, you know, everyone's still happy with it. But I'm a self-employed engineer. Of course, I work on random other projects 75 percent of the time and a lot

of them it's always tricky because a lot of them could become apps but something you learn is um the moment you release an app you now have to maintain that app for the rest of your life and so I never want to release I used to think I'll just throw out all these apps and you know whatever sticks sticks but now I've learned that you really want to be careful what you release and so I'm a lot a little slower to release new apps these days you gotta maintain it right if it's if it is successful you gotta learn to love it basically right success can be its own worst enemy you know a nice thing about being self-employed is you don't really have to do anything if you don't want to if you're paying

the bills but then if you have all these people using your app and they want support and they want all these things, it's something you, it's a job. It's a real job. You go from one boss to thousands of bosses. That's exactly it. This episode is brought to you by our friends at Influx Data, the makers of InfluxDB. In addition to their belief in building their business around permissive license open source

and meeting developers where they are, they believe easy things should be easy. And that extends to how you add monitoring to your application. I'm here with Voychek Kajan, the lead maintainer of Telegraph Operator for Influx Data. Wojciech, help me understand what you mean by making monitoring applications easy. Our goal at Influx Data is to make it easy to gather data and metrics around your application. Specifically for Kubernetes workloads where the standard is Prometheus, we've created Telegraph Operator, which is an open source project around Telegraph, which is another open source project that makes it easy to gather both Prometheus metrics as well as other metrics such as Redis, PostgreSQL,

MySQL, any other commonly used applications and send it wherever you want. So it could be obviously in FluxDB Cloud, which we would be happy to handle for you. But it could be sent to any other location like Prometheus server, Kafka, any other of the supported plugins that we have. And Telegraph itself provides around 300 different plugins. So there's a lot of different inputs that we can handle. So data that we could scrape out of the box, different outputs, meaning that you can send it to multiple different tools. There's also processing plugins such as aggregating data on the edge

so you don't send as much data. There's a lot of possibilities that Telegraph Operator could be used to get your data where you are today. So we've permitted metrics, but you can also use it for different types of data. You can also do more processing at the edge

and you can send your data wherever you want. Wojciech, I love it. Thank you so much. Easy things should be easy. Listeners, Influx Data is the time-series data platform where you can build IoT, analytics, and cloud applications, anything you want on top of open source. They're built on open source. They love us. You should check them out. Check them out at influxdata.com

slash changelog. Again, influxdata.com slash changelog. Frank, sometimes you find yourself in a position of needing to write some code that you're just not sure how to write. I know this about you because you wrote this down. And there are certain steps you take when you're stumped. No huge revelations, just hard-earned advice. I'm transliterating your opening paragraph and putting it in the third person, even though you wrote it in the first. So this sounds weird.

That's what's going on here. But the point is, you wrote this post, your practical guide to solving hard problems. And there's nine steps. You want to kick off this conversation that's walking us through maybe some of the hard problems you've had to solve or the types of things that stump you. And then we'll get going into like actually your steps. Obviously, this is prescriptive to a certain degree and what you think works well for you. But it's more, I think, maybe fodder for us, something to think about how each and every one of us

solves problems is going to be different. But I think there's some similarities. So open us up, will you, Frank? Yeah, sure. Just for some context, I was having a conversation with a friend. We were talking about Twitch streaming. We've both been doing Twitch streaming. And he was talking about how hard it is to solve hard problems and Twitch stream and code at the same time.

It's a bit of a high-pressure situation. And so I was thinking to myself, you don't get to do MetaThought too much. What is my answer to that? And what I decided was I have totally fallen back on programming advice I think I received in the 1980s, which was, if you need to solve a hard problem, just talk it out first. And what that means is just kind of write it out long form without having to worry about the details and then break it down into subproblems, solve those subproblems. So that's what I meant by no big revelations here. It's something I totally read in the 80s. But it was something that I realized I do a lot on the Twitch stream

because in a high-pressure situation where you need to solve a problem, you fall back on what works for you. Well, what works for me is writing out really long function names and just saying what the function needs to do and return and that kind of stuff. But hard problems, I wrote a C compiler and C interpreter for my circuit simulator. So while the circuit simulator is running at, let's call it a megahertz, or at least trying to run at megahertz, it's also executing C code, it's also talking to hardware, it's also drawing to the thing. So just writing a C compiler is a pain, writing a C interpreter that does that at the same time is a pain. I have another IDE that does live IntelliSense with ML completion.

These are features that even desktop IDEs sometimes don't have, and I have that running on iOS just fine. Even today, I was working on a problem where I'm trying to do these 3D LiDAR scans and turn them into a mesh, and there is this algorithm to do these 3D LiDAR scans and turn them into a mesh. And there is this algorithm to align these 3D scans called the iterative closest point algorithm. And it's a tough little algorithm. And not many people want to implement it. When I scoured the internet for solutions to it, there were, you know, 20 of them. Half of them had GPL license that I couldn't touch.

The other half are in Python, a language I'm not using for my apps. Others would be in C++, and they have so many dependencies, I can't do them. So you come down to this unfortunate realization that, oh my god, I have to write the algorithm myself. Good luck. Those kinds of hard problems. Always in service of, generally, these are the kind of problems of, I'm trying to add a feature to my app. These aren't the other hard problems, which are,

there's a bug in my app and I'm trying to find it. That is a whole different kind of terribly hard problem. This advice won't help you too much with. Right. That one's more reactive and these are more proactive. Yeah. This is how to push your own limits, let's say. I don't like to do boring programming on Twitch.

I like to always be at the edge of my own skill level. And so it's nice to have a procedure to fall back on when your mind is racing and you're wondering if you're looking like a complete fool in front of a live audience. Well, I guess your number one is somewhat confusing then because if you're in front of a live audience, number one says somewhat confusing then because if you're in front of a live

audience number one says think hard about the problem for a few weeks before typing any code so now I'm just imagining you

live on Twitch just sitting there staring staring off into the distance thinking hard what is Frank he's been at this

for a week what's going on with this guy he hasn't moved it's a long Twitch stream it does happen but usually I catch myself around the one minute

mark. I realize I've been completely still for one minute. No, what happens is I think about the problem for two weeks before the Twitch stream, where I feel like I've solved it in my head. You know when you get that feeling, I've solved it in my head, now I just gotta dump it out in code? That's usually

the point I want to be at when I start a Twitch stream. But this all comes from i'm i'm just a slow thinker i'm terrible at interviews someone will pose a problem to me and i'll just stutter and stop because i realize i don't think what i do is i do other things and then the back of my head solves the problem and then it informs me when there's a solution and so i need that kind of time period. It's just how things work for me. And so I don't ever like to just jump into code. I like to let it percolate in my head. It's so much easier to change architectures in your head. It's so much easier to change programming languages. It's so much easier to change libraries. There are no version dependency failures in your head. So I highly recommend

write as much of it in your head as you can before you sit down because the moment you sit down, now you're fighting a compiler and a runtime and all that stuff. Yeah. That's fascinating because I don't disagree. But then in practice, I find that my style is more twiddling bits around. Like I think as I write, you know, and if I'm staring at a blank canvas

or just sitting there in my head, and like you said, you admitted, you don't like sit there and stare off in the distance. You do other things and it just kind of like, you think about it over time. I don't know, like shower thoughts kind of a thing. And that's when the solutions come. But most of my stuff in practice,

I write this way as well, prose. I actually edit while I write. And I know that like people who write tell you not to do that. They say like, write a rough draft, just get all your thoughts out and then go back, either edit that draft or throw the draft away and keep the parts you like and rewrite and rewrite. But I will literally edit as I, as I write and I edit as I code. As I code, I'm thinking, and then I'll throw stuff away. And it's different than that. But I'm wondering if I need to differentiate between when I'm really stuck. Sometimes I don't know I have a hard problem until I really get stuck. Whereas in this case, you know, like, okay, I've got this algorithm I need to somehow

implement. And so you can think about that without having to twiddle some bits to realize, I don't know how to do this. Sometimes I don't know I'm in a hard problem until I hit my head against it. Yeah, when you're doing calculus, you don't want to think about algebra. The algebra should be cold. There is the high level problem I'm trying to solve, how it fits into my app and all that stuff. And then there's the low level, what class am I going to put this into? What module am I going to put this into? How am I going to actually share the data around? That is just glorified bookkeeping. And you can do that as a background process while you're thinking about the harder problem.

So I like to constantly make progress, so I constantly edit too. But I don't think of that as a bad thing. I think of that as me doing something mundane while I procrastinate on the hardware problem. You know, sometimes you got to clean up the code to get it to a place where you think you can actually solve the hard problem too. Some refactorings are required. But a huge chunk of programming is just regurgitation of data paths that you've created for the last 10 years, and you're just putting them back into this app. Yeah. Unfortunately. It goes both ways. Sometimes, like a lot of what I'm going to describe in this blog was a top-down perspective on it, but I love to start at the bottom, too.

Like, who doesn't like to write a little math function and then a bigger function on top of that, a bigger function on top of that, and work your way up? But at some point, you're going to have to integrate that into a bigger system and come back down again. So just different ways of attacking. Right. Yeah, sometimes I actually accomplish a lot of stuff while I'm not doing the coding that I'm supposed to be doing. I used to call it procrastinate coding. It's like, look what

I accomplished while I was putting off what I know is a much more difficult task. And at least I feel like I am making progress and it is real progress right like you're doing things that matter they just aren't the things that you need to be doing eventually yeah you know you're just kind of or you write some unit tests yeah you know just just test something that's already been tested you know just to build confidence you know like there's a test uhfirst development, test-driven development. But I don't know. Me personally, I tend to write something

and then use tests to kind of prove that it's working. But other times, a test-first can definitely help you out just to get the brain juices flowing and all that kind of stuff. Sure. Yeah, I find it's helpful when I'm not sure what an API service might look like or how I want to use the thing.

A lot of times my designs come out of my desire to use it in a certain way in the area of the code that I'm going to be using this thing. And so I'll use test-driven for that because what is a test if not the first user of your API? And so you can actually write out the API the way you think of using this function or this module in the tests, and then obviously they're failing. And so you're kind of out the API the way you kind of think of using this function or this module in the tests, and then obviously they're failing. And so you're kind of doing test-driven development. But when I really don't know what I'm doing,

I don't test first, I test later. But when I kind of don't know what I'm doing, then I test first. It's just a gray area. That's why my number two is like, just figure out what your inputs and outputs are. What are we actually talking about in this thing? So I want to solve this problem of aligning LiDAR scans to create a mesh.

It is a multi-step problem. You've got to align the things. You have to create a distance function for it to turn it into a solid. You have to sample that into a voxel grid. Then you have to use marching cubes on top of the grid to create an actual mesh in the end. That is a big long process, but in the end I can say, well, it takes a set of point clouds and outputs a mesh. So I start with a function, convert point clouds to mesh. And you know, you just start there and sometimes you just gotta, I like to make progress.

And you know, typing out that long function name, I have no idea how to implement that function, but just typing out that name, giving it some arguments, some parameters, and giving it a return type, that makes me happy. I feel like I've made some progress. And then you can even write a test for that. The test's the dumbest thing, but it's doing something.

And then you can build your test from there. It sounds like momentum is a characteristic you're both describing because in a lot of cases, solving any problem, whether it's coding or not coding, or just doing it, like if you're procrastinating, I guess if you're not coding, you're kind of procrastinating. So the solve of the problem of the procrastinator is just get some motion, get some momentum. And before you know it, you've got enough inertia going that you're going to carry through. God, you nailed it.

That's perfect. I mean, that is the problem too. I don't have to work on a hard problem. I could just maintain apps forever. That'd be fine. So where do you get the energy or the incentive to do it? Well, you got to start small because the big problem is too hard. You start with a small one and you build up that,

I call it confidence, but momentum is the great word too. But you're also building up confidence. Maybe I can actually solve this. It's kind of like that old adage, how do you eat an elephant one bite at a time? I think that's the way it goes. But that's really what the hard problems are, right? Like, how am I going to eat this elephant, for instance,

a big thing that's tough and all these. And it's like, well, momentum, right? Well, you got to get started. And I really liked the top-down approach for this that you described because the details are where the difficulty is, but your end goal and your starting place are actually relatively straightforward to define. In fact, if you can't define your end goal, then you got some other thinking to do, right? Like, well, and I've done a lot of client work where that's a lot of the conversation I have with them is they're describing this problem or this solution or whatever they're describing to me. And I have to either derive from them or have them explicitly state, well, let's forget all of this stuff you're saying. What exactly do you want it to do, right? Like what,

that's your outputs, right? Your inputs and your outputs. And if you can define well your outputs, what are you trying to accomplish? What's the goal of this hard problem? You know what your inputs are because you're already there. That's where you stopped, right? You stopped at your inputs and you know your end goal. And now you have something that's tangible. Like you said, that's momentum. And you can go from there. Now the solution in between is going to be a long and winding road. You may find out actually there was some other way of attacking it that made it into an easy problem but you're going to find that along the journey but if you don't know where you are and where you're going then the rest of it is not

procrastinating it's actually just like mindless wandering there's no good end to that yeah i also like in point five you talk about sprinkling and fun which i think is this psychological hack you know you say go implement a few of those functions. You know they're not all hard, and some may even be fun. So I think it's important to, as you're tackling hard challenges, to stretch yourself out a bit by stretching yourself or being at the edge, you said before, of your comfort zone, so to speak. But also sprinkling some fun, because that's going to kind of keep the dopamine hits going. We are monkey brain. We know how the brain works to some degree. There is some

knowledge on that. So why not actually leverage that in your style of getting something out of yourself? Yeah, call this hacking the programmer neurosis or something like that. You have to have that positive reward. Otherwise, it becomes drudgery. And we don't do good work when we're doing that kind of stuff. So you have to get those dopamine hits and all that. And I mean it. The hardest algorithms I've had to ever implement, it turns out only 10% of the final code was actually hard. The other 90% was bookkeeping, moving it from this data source to that data source, making web requests, authentication, something terrible like that. You know, the terrible stuff that's all just rote.

We can do that. And so, A, keep the momentum up as like before, but also some of those might be fun. Probably not the authentication part, but maybe you can show like a cute emoji somewhere or a profile image or something i love graphics programming so if i get stuck on a problem i'll just start drawing debug information normally i rely on printf debugging like all other proper programmers yeah but eventually like the problem will just be so hard and i really have to get to this limit but i'll start drawing to the screen to try to like visualize the data in a way that I can comprehend a little bit better. And then you can save that for later and put that as an advanced settings mode for the user or something like that.

But yeah, I like making progress. And for me, that's usually do something you know and love like graphics. And that'll just help you keep moving too. It seems like this might be leading towards a solo dev, too, like you're by yourself. Does this need to be flipped entirely differently in terms of one through whatever number, eight or nine? I think it's eight. You know, if you've got a group. And the reason why I was thinking this, I almost brought up, Jared, sorry, Silicon Valley.

Gosh, not again. Because Silicon Valley, the TV show, is famous for this algorithm that was created, right? Is it famous, though? The whole series was about Richard Hendricks and this algorithm that was created, right? Is it famous though? The whole series was about Richard Hendricks and this algorithm, my algorithm, right? And I think it was in like episode one or two, by the time they got to like TechCrunch Disrupt, they had like solved middle out, right? But they did it as a group and it was fun. So talking about fun and momentum, it made me think about them and solving this algorithm

problem they did as a group. And it was only because they're such fun characters, I guess. I mean, obviously it's TV, so it's not real, so to speak, but it's based on possible reality. I'm just curious, does this translate from individual developer to how you think and get progress on yourself to a one person team to a two or three or four? How does this translate to groupthink? Well, it's been literally 10 years since I've worked on a properly big team. But I would say it still applies just fine because you get an issue assigned to you and your boss or someone's expecting you to fix that issue unless your company is purely people

doing whatever they want. There's usually some level of organization, some task has been assigned to you. And so you would apply this general procedure to that task. What you benefit from in a large company is when you get stuck on any part of it, you can go talk to a coworker and be like, hey, I made it this far. Help me get over this next little hurdle. That's the benefit there. It's something I'm jealous of being an individual worker, because if I run into a hard problem, especially in a field where I don't have close friends that are also in that same field, I'm SOL, you know, I'm just up a creek without a paddle. Whereas at a company, you're surrounded by smart people. So a lot of benefits to being a

solo dev, but that's not one of them. You are so lucky to be able to tap into other people's brains. So I probably should have put that on this list somewhere. But for me, where that is, is searching the academic papers and seeing what the research scientists are doing. Those are my closest peers that I have easy access to, aside from Twitter, help, help, help, help, or Stack Overflow, I guess. So real quick, let me summarize the process because we've been around it and we're talking about it. But we stopped off this conversation with create this one function. So we talk about it's top down. And so your overarching advice is define your inputs and outputs, write down this function

that doesn't do anything that has the entire thing in the name, basically, like one big function. And then inside of that function, you're going to write kind of the steps that you can currently see, right? Like maybe it's six steps that you think are the steps. Write those as functions. And they just have a not implemented error.

They're not done yet. You're basically just scaffolding out the idea of what the code might look like when it's done to get some momentum going. And then it's like rinse and repeat or drill down. So empty functions all the way down until you get to the point where you can actually implement something. So this is kind of like a programmer's

way of saying, break it down into small problems. And one byte at a time and then as Adam referenced in step five, do the ones that you know are the easy ones or the fun ones. Leave the authentication till last. We always will, right?

And then you're left with like, actually when you do that process over and over and you just iterate that, you're going to have like most of it solved because most of the hard problem is not the hard part. It's like, it's overwhelming. But like you said, a small percentage of it actually is.

Let's call it complicated. And everything else is just a bunch of steps that overwhelm you until you break them down. So once you're there, then you're going to have what you call in step seven, 80% solution with a few pesky functions left. And those pesky ones are the hard part. And then you say from there, now it's time to go out to the interwebs,

see what other people have done. In your case for this algorithm, you found this Python project. You're not going to pull it in, but maybe you'll just read their code and see how they implement it and see if you can port some of that or at least get inspired by some of that

to solve those very last hard problems. Now, I don't work in large teams either. I have worked in teams, though. And I will say that this process is very teamwork oriented. It can be because every step along the way, I mean, you could whiteboard this thing up into the point where you're implementing those individual functions, right? So you can write down this on a whiteboard. You can name them like functions. You can say, all right, what other steps do we have? Maybe I missed one, I thought of three.

And then somebody else thinks of, oh, don't forget, there's this other step. And so this could very much be done in a collaborative way, which would probably get you there faster, better than you would by yourself without getting blocked until you get to the point where you are implementing individual functions, right? Then just one person's like, well write the auth jared you know while i do this algorithm part or this shader and so i

think that while it is written with like you by yourself in mind i think that it definitely is a kind of process that you can do as a team and have a lot of success. Yeah, I like your whiteboard analogy. I wish I used mine more. I tend to draw on it and then leave what was up there for far too long. The old advice used to be write pseudocode, but who's got time for pseudocode? That's kind of pointless. That's just silly.

Our modern programming languages are high level enough that we don't have to worry about low level stuff. We can focus on the algorithm, moving data around, that kind of stuff. So don't get bogged down in those kind of details. And yeah, especially if you're in a company, you can ask for help. I'm amazed at GitHub as a resource. If we had done this even 10 years ago, I'd say, I don't even know what my answer would be because it was so hard to find existing source code out there. But now GitHub, you go to that global search, you type in any term you want, filter out all the ones that are GPL so you can actually use it, and then go read that source code and learn from it.

GitHub has done so much to benefit the world and the community. I don't think that you should just go in there and pull in libraries all the time. One skill I developed early on in my career was reading code in one language and retyping it out, translating it really quickly into another language. Because dealing with C++ dependencies is terrible. Even Python dependencies are slightly terrible. I work mostly in the.NET world. We have terrible dependency issues also, but they're not nearly as bad as those other languages. So quite often if I find something in another language, I'll just retype it. And the nice thing about that is you learn so much

when you force yourself to transcribe someone else's code. You can't just cheat. Like, oh, I told we understand that part. Well, can you translate it into your native language? Let's see you do that. Tough guy. So I like to do that stuff too, just as a learning thing and an opportunity to grow.

Yeah, it's definitely fun because it's not hard, but it's mind engaging work, right? Like you're not, you can't do it mindlessly, but it's not a hard problem, right? It's like, well, I mean, okay, make sure that it works in that other language first, you know, maybe download it, compile it and run it before you start cargo culting it. But once you know that it works and you also don't know just because it's on GitHub doesn't mean it's good, right? Like the way they've done it might not be the best way of attacking

the problem, but if it works and you can run it, then just going through that process of saying, okay, read this. how would i write that in this language you're going to learn a lot actually on both sides of that so definitely uh you know plus one your statement there and recommend it as a process and much better than writing it from scratch yourself right like you got somebody holding your hand along the way well it's also neat to see it from a few perspectives. Going back to that LiDAR scanning problem I mentioned, a big step of that is the marching cubes algorithm, which turns voxels into a mesh. And it's a pretty standard algorithm. There is one standard form of it, and then there is an improved form of it. Everyone implements the improved form of it.

But it's a little bit of hard code to read. It's just written a little bit funny. I think the original is in C, but it's a funny dialect to see. And it's really fascinating to see other people's translations of it into other languages. You can tell they copied it, but you know, they modified it a little bit. And so I would look at the JavaScript version of it, the Python version of it, the C++ version of it, all these just to get a general, okay, this is how it works. And this is how I'm going to make my version yet another variant on it. But again, that's almost rote work too. I worked on that code because I was pretty confident I could find resources for it when I was ignoring a much harder problem, which is the image registration where all the images have to line up because that's a much, much harder problem

than this other one that's been a known technique since the 1980s. And so it was fun to just spend a couple days working on a 1980s algorithm while I percolated the thoughts in my head for the other one. It's like a whole new level. It's like there's one level which is, this is hard for me. And then there's another level which is like, this is hard for humanity. Or this is an unknown thing that maybe somebody

has solved it in some lab or inside some proprietary company somewhere. But there are problems where you're not going to find them out there on GitHub. Or what is it called, the archive with the X in there? Yeah, archive with the X in there? Archive with the X, yeah. Any paper. This episode is brought to you by our friends at WorkOS.

When it comes to adding enterprise-ready features or selling to enterprise customers, pro teams, engineering departments, developers, they're all faced with a choice to ignore and focus on viable features or get distracted and learn how to integrate with complex legacy systems. And I'm here with Michael Greenwich, the founder and CEO of WorkOS, who knows there's a better way. Michael, what do teams at Vercel or PlanetScale know about the world of enterprise features that no one else knows? The world of enterprise features is full of acronyms. Typically, they're like these three or four letter acronyms like SAML or SCIM or SEAM. It's like secure event information event management. There are these long kind of like really obscure acronyms that most developers aren't familiar with. They've never really heard of. And this is what ITM's require you to build integrations around.

They say, hey, we need SAML or we have to have a SCIM integration, etc. And for companies like, you know, PlanetScale or Vercel that are building on really modern stacks, building with React and like, you know, cutting edge JavaScript technology and like web applications. They're really having to go integrate with these old legacy platforms and systems like SAML's built around like XML several generations before. And so I think when those companies looked at what to do in this scenario, they have deals that are getting blocked because they don't have something like SAML single sign on. And their engineering team is like, do we really want to spend all the time to go read the spec and learn how this works and dive into all the different ways this can break? And in the case of SAML, there's a bunch of instances of security of vulnerabilities that have happened over the years. Do they really want to spend time on that? Or do they want to

spend time building the unique features, that power of Roussel, like focusing on Next.js and focusing on those applications? And for these companies, they don't. They don't want to spend the time thinking about SAML. They want to be able to hand it off to someone who can really go deep in that and obsess over it. And so we're sort of like, you know, the partners to all these companies that goes really, really deep around, you know, these acronyms or obscure technologies, making sure they don't just work really well, but they work everywhere with every single system. And we've tested it end to end. And it even has this kind of compounding effect, the more people using WorkOS, kind of the more stable and more robust it becomes. And what it

really does is lets companies like Vercel or PlanetScale or Hopin or Webflow focus on those product features and for their best engineers to spend time still delighting their customers and not necessarily doing these enterprise IT integrations. That's awesome. Thank you, Michael. So even if your team isn't focused on enterprise, you can still leverage WorkOS so you're not turning enterprise away. Learn more.

Get started at WorkOS.com. They have a simple pay-as-you-grow pricing plan that scales with your usage and needs. No credit card is required. Again, WorkOS.com. And by our friends at Retool. Retool is the low-code platform for developers to build internal tools. Some of the best teams out there trust Retool. Brex, Coinbase, Plaid, DoorDash, LegalGenius, Amazon, Allbirds, Peloton, and so many more. The developers at these teams trust Retool as the platform to build their internal tools, and that means you can too.

It's free to try, so head to retool.com slash changelog. Again, retool.com slash changelog. Again, retool.com slash changelog. We're kind of back to some psychological type things too because whenever you have a challenge i guess just generally as a human it's often perspective that can give you that shift to see things differently and i've heard it be said like if you're familiar with cameras and focal lengths you might have like a wide angle lens like a 12 millimeter or 20 millimeter that gives you a wider point of view. However, you know, when you go into portrait mode or something like that, you might go to like an 85 mil or something like that. That's got a longer lens. The point is,

is like, if you look at the image that comes out of each of those lens types, which is basically perspective, it's zooming into micro and zooming out the macro. It's that perspective shift because when you see something from somebody else's perspective, like in this case in particular, like Python or a different language, you get to see, and I think that's what we do here with this show too, is we've never been like a camp type show. Like we cover Ruby or C or only particular languages or only particular camps because it's always about like, okay, at large, large how we solve this problem with code or with programming and being able to see how somebody might do it in javascript or a different language is like okay their constraints are x they did it this for this reason they also have npm you know in this massive registry with like millions and millions of

developers pouring into it so because of that they can do this this and this whereas here you don't have that ability or constraint and so that you do it this way, you write it all yourself, et cetera, et cetera. So I think perspective shifting like that really gives you a leg up because as you said before, you know, stand on the shoulder of giants, like get somebody else's perspective who's been done that a little bit before and translate it to, you know, your particular need. You say yet another, but if it's an iOS app and it's not open source, then yet another is just fine, right? It's a bespoke specific need you have, so why not yet another it?

Right. That's nicely said. The perspective is so important. I was working on another compiler, a different C++ to IL. IL is the Intermediate Language.NET Apps Run On. It's the Managed Runtime Language. It's a compiler. It's very difficult to write. It wasn't actually going from the C++. It was going from LLVM's intermediate representation. So it went from IR to IL. So I'm going from these two different representations of a program. And that was one of the most sophisticated pieces of software I've written, maybe in my career up to this point, to the point where I got really stuck on a part of the problem. The way the two languages represent data is just different. Okay. I actually had to refer back to

the Dragon Book. Do you know what the Dragon Book is? It's the Compilers, Principles, and Practices, a very famous compilers book written in the 1970s. And I was reading Wikipedia page after Wikipedia page, modern treatment after modern treatment. What I was trying to do was synthesize these phi nodes. It's a complicated thing of data management. And I couldn't understand any of the algorithms until I opened the Dragon Book and saw in the 1970s, their pseudocode implementation of the algorithm, which threw away all the details, ignored all these modern advances that aren't actually advancements, you don't actually need them. And written out in this very clear style, in all capital letters, I don't even know what language they were pretending to be in that book. But just finally getting it from this old, old resource and realizing, oh my God, in the 1970s, there's chapter five, section four, and they describe exactly the problem I'm having. And they, oh my God, even better, have a solution to it.

And then you can transcribe that solution from their crazy whatever language that was into whatever you want to be using and you learn a lot during that process that felt so good to me when i finally found that it's like uh coming across hidden treasure somewhere and you're like look at this look what i found i knew they were smart that's crazy you want to tell somebody at that moment but nobody not that they don't care they just that they don't care, they just can't care. They just can't care. They can't care. It's like, I have no idea what you're talking about, Frank. Okay, but congratulations on solving the problem. Well, there's a little street cred, too.

Just knowing about the book shows that you're semi-interested in compiler technology. Actually having a use for the book, I feel like I became a computer scientist that day. I actually applied something from the Dragon book. It was a real high point in my career, to be thoroughly honest. And that's where you're standing on the shoulder of giants. It's like you graduated from Hogwarts that day. You became a wizard. You became a real wizard. By copying a wizard spell, but yeah. But I realized the wizard spell worked. Yeah, I was very Harry or Hermione there. So this is a related question, a little bit off topic, but I thought about it because Adam started talking about NPM

and we're talking about finding solutions and being comfortable with other people's code. I'm curious what your appetite is for dependencies. It seems like you're probably the kind of guy who's more on the not invented here side of the spectrum where you probably implement side of the spectrum, where you probably implement most of the things yourself. But I'm curious, when do you pull in a third-party library or a dependency?

Are there use cases where you're happy to do that? Or are you pretty much right at all yourself? I honestly think I've hit maturity when I look first for someone else's solution. I don't always do that. I definitely lean towards the NIH side. I would say when I started my career, I was full, right? Just completely NIH. I wanted to know how the universe worked.

Therefore, I'd program the universe. I'll do everything from scratch. Nowadays, there's just no time for that. Our apps are so much bigger than old apps. You look at apps from the 1980s and the 1990s. They're so wee. They're tiny compared to what we're producing these days. The amount of libraries that we pull in, the amount of dependencies we pull in.

For example, I use all of Apple's frameworks. Every single one of them. All 5,000 of them. I use every line of code out of all of them. You use all of them. Because there's just a wealth there. Well, it's kind of amazing because I'm a.NET programmer running their apps on iOS. So I have the entire.NET ecosystem at my disposal, and I have the entire Apple ecosystem at my disposal.

So chances are something good has been written in one of those two worlds, and I can pull in packages. Me personally, and I guess as a company, I'm happy to take first-party dependencies. I feel very comfortable taking first-party. Third-party, I'm a little more suspicious about. If someone releases a library that does exactly what I want, and I look over their code, and it does it roughly in a way I approve of, I am very happy to take a dependency on them. 100%. But I don't like to take dependency on our third-party frameworks and things that are prescriptive and try to tell you how to write an app and that kind of stuff. So I'll pull in feature dependencies, but I'll rely on the first party for my frameworks, and the rest is up

to me, I guess. So are you writing iOS apps in C Sharp? Yeah, C Sharp. I actually use a lot of F Sharp these days. That's my current favorite language. And Apple's tooling just works honky-dory with all the.NET stuff, or is there some sort of

layer between those two? There's a little layer, but it's mostly just C++ wrappers over a C API. You're just trying to make the API a little more friendly to use. And then.NET programs can be compiled down to native code, so it's not an issue. You're just talking to

their APIs as any old program would talk to their APIs. And that's been around since 2008. And I adopted it just because better debugger support. I'm kind of a programming language bigot, so I prefer those programming languages. And I just it just because better debugger support. I'm kind of a programming language bigot, so I prefer those programming languages. And I just know that ecosystem so well at this point

that it's my strength. Why would I ever give up a strength? That's dumb. You don't do that in business. You play to your strengths, and it's a strength of mine. So do it. For sure. It's a good system, though.

Good debugger. Good threading. Garbage collector. Every language should have a garbage collector. Come on. Life's a good system, though. Good debugger. Good threading. Garbage collector. Every language should have a garbage collector. Come on. Life's too short to manage memory. You're not going to get an argument from me on that one. Although I did just hear a fellow on GoTime during the Unpopular Opinion segment who stated that to this day he thinks C is the best programming language.

And he gives his reasoning on that episode. And, well, to each their own. C is the best programming language. And he gives his reasoning on that episode. And, well, to each their own. C is the universal assembler. It's a strange thing to say on a Go podcast, but nonetheless, he's trying to be unpopular. It's not a bad opinion. If you want to write a cross-platform library, I would write it in C.

Every platform can compile C. And even better, most high-level languages combine to C a lot easier than they combine C. Every platform can compile C. And even better, most high-level languages can bind to C a lot easier than they can bind to C++ or Ruster or something like that. So C is still an excellent choice if you're willing to put in the pain and the effort of dealing with C and you really want a cross-platform library. C is not a terrible option. I'm biased towards binding. I really want all languages to be able to use all libraries from all other languages. As much as I love transcribing code, I really wish I could just pull in a Python module.

I really wish I could just pull in a Ruby module. But because of reasons, we have to keep our little isolated language worlds. It's terrible. That kind of speaks to point nine then, some degree or at least tangentially, which is once you've stood on all the shoulders of the giants and there's no more to be had. Well, it's you. It's all up to you as you say. Think big. Your career depends on it.

And you even prescribe a bath, which I totally agree with, which is this whole idea of like step away to get unstuck. Yeah. Perhaps a shower i think i i have a lot of my great thoughts or at least mostly great thoughts you know away from you know the actual work itself you know oh yeah i could be on a bike ride with my son i could be driving i could literally be showering you know or doing something mundane it's like okay now there's that now i understand how i gotta go tackle this or at least one idea that I can begin to iterate again and kind of go back through step one through nine again to some degree,

which is this sort of cycle that you might go through. Yeah, you're basically, I should have put go to one because now you're back to thinking about it for two weeks. You need a break. You're too deep in. You've lost the way. You need some rubber ducks. I probably should have put some rubber ducks mentioned in this

because I totally abuse my friends, and they have no idea what i'm talking about but i'll just explain a technical problem to them and it just helps you know it's co-workers this is what co-workers are for too i have to abuse my friends for that same thing my wife is my co-worker she's like i am so i love you however i'm so done hearing you talk. I don't even know what you're talking about. And I'm like, babe, just listen, please. I mean, I will talk. You can just nod your head or you can just be in the same room. But if I can talk it out loud and just think out loud, I'll get just thinking it for some reason.

For some reason, like it could be in your brain. But for some reason, putting it out into the world vocally, speaking the words, making your brain and your body say the words, something happens there when you translate it actually to English and put it out there. Pete You proceduralize it. Spoken word is a necessary procedural, so you got to put things in an order that requires you to think about the order for a minute. And that kind of gets us back to steps two and three of just write the function name down and write the order down. Write what words you would tell your wife or your mom or whoever you're going to talk to about this

problem. Write that out, but use C syntax instead of English syntax for that. But just write out that problem. Right. Yeah. Rubber ducks are so amazing. You get a lot of people talking to themselves too. If they don't have any friends or coworkers or moms or dads or wives or whatever, like, you know, you're going to get a lot of people talking to themselves which i'm totally cool with i don't know if you guys talk to yourself often but every once in a while you'll catch me talking to myself i am always narrating in my head i keep it i keep it in my head but you know the other fun hack and all this stuff i don't know if you guys have used GitHub's Copilot yet, but you write out long function names with some comments and a little

bit of context. They'll start filling in the gaps for you. Woo, brother! That code just starts writing itself. So guess what? Long function names are back. The clearer you are, long variable names, you know, you've got to give that AI a little bit of context once it's got some context it's seen a lot of code it's going to

write some code i like that it's like a quantifiable argument towards verbosity and programming which has always kind of been a stylistic argument you know like more information versus overload you know verbosity versus terseness i think it it was Shakespeare famously said that brevity is the soul of wit, but it's not necessarily the soul of readability. That's my part. I had the second part. Shakespeare didn't say the second part. If he did, the guy's brilliant.

But now it's like, hey, don't be brief. Be verbose, because you got to give that thing something to move on. You don't want to have to write the actual code, do you? It's almost like a code search, too, right? Like you're putting code, do you? It's almost like a code search too, right? Like you're putting the function name in. It's almost like a code search in a way. Yeah, it's a way better stack overflow search or something like that.

It's like a wish is a dream your heart makes, you know? You just kind of put a function name into the world and just hope that implementation comes back to you. You know, they talk about how test-driven development changes your style of programming. Copilot has changed my style of programming. Because it totally works very well with this top-down approach. The details are the details.

Guess what? Bookkeeping, boring code, that's the code AI has seen the most of. And that's the one it's really good at filling in. It'll make mistakes on the complicated part. But you tell it, save this to this table, it's going to write that SQL statement perfectly. Wow. Anyway, until the bots replace us, we can still keep working on the hard problems. They still can't solve those ones. You had a show on this whole new paradigm where it's AI-assisted development. And we talked about that, like, will we be replaced? And the consensus was generally no.

Mostly no. I mean, maybe at some point. It lacks the creative part. You still need the thinking, right? The going away and thinking part is still the thing the machine can't quite do yet. But use it for all that bookkeeping code, all that boilerplate code. Of course, I want the AI to generate that. I don't need to concern myself with it. It definitely changes your style of programming. Similar to what you said about garbage collection, I heard recently.

And you guys probably both have desks and wires and stuff like that. So I heard somebody say that life is too short for wire management or cable management. And I kind of, I tell it, it's almost the same thing. It's like, you know what, boilerplate code, forget it. Life's just too short for boilerplate code or cable management or garbage collection. Like, skip it.

You know how many button-on-click handlers I've subscribed to in 20 years of writing UIs? I don't ever need to write that ever again. I'm more than happy for the AI to do that. I don't think it has that creative aspect to it yet, of course. It just needs to be 100 times bigger, and then it'll have that creative aspect. Like, it's not going to create Wordle, but it'll help the heck out of you to write Wordle, no problem. Mm-hmm. Right.

Frank, it's been fun going on this journey with you. Yeah. What I appreciate most, honestly, and I think this is a tribute back to you, but also a word of wisdom to others listening, is put your thoughts out there. I think the world benefits when we share our wisdom, and I think this is definitely wisdom. Because you're going to have somebody else come along to the show or to the blog post itself,

you know, outside of the podcast and just hear from the ground level, how someone else who's been in the trenches since the eighties or longer, who's been embedded systems to iOS, to.NET, like all these fun things you're doing and just kind of like gleaning from your wisdom, which I really appreciate. So thank you for for writing it thank you for sharing your thoughts here with us today and we appreciate you frank oh thank you very much uh a quick lesson i learned in twitch was i never wanted to make a mistake and then finally someone told me it's when you make your mistakes and when you struggle that's when it's most interesting because you always want to see how people get out of the hard parts the easy parts are the easy parts yeah so i appreciate you having me on uh really life goal here accomplished

check mark and all that kind of stuff so uh it's been really fun chatting with you appreciate it we're honored to have you man it's been awesome thank you frank that's it thanks for tuning in this show is done if you haven't subscribed yet now is the time and to changelog.fm for all the ways and if you dig what we're doing on this show you might enjoy other pods we do in the changelog universe such as js party here is a sample from episode 212 where Evan Yu describes faster feedback loops with VEET. When we have a large Vue project, it can still take like four to five seconds, even if you just edit a single file, and then for the hot module replacement to happen. And for me, that really kills the feedback loop, the overall flow when I'm working on something because I'm just making a simple tweak.

I have to wait five seconds and it just like during that five seconds my mind gets a hold of something maybe I see a message your Twitter message or something that I just get distracted the longer the the feedback loop is the more chances that you get distracted or you just lose your flow state when you're working so I was really wishing that I could find a solution that gives me that really instant snappy feedback loop. When we first started working on the web, because you just load a script into an HTML file, you refresh the page, everything is, you just refresh, everything just reloads, right?

There's, you don't have to wait for things to come pop. So native ESM kind of gives you that really snappy thing, right? You just write native ES modules, the browser can handle it. It's really fast for most apps. If you're just loading maybe a hundred modules, the speed is very, very good, especially during local development. All right. Continue to listen to that pod at jsparty.fm slash 212. That's episode 212. Big thanks once again to our friends and our partners at Fastly for that super fast global CDN.

Check them out at fastly.com. Also, thanks to Breakmaster Cylinder for making all of our awesome beats. All right. This show's done. Thanks again for tuning in. We will see you next week. Game on.