In my first-ever live stream, I used a TDD exercise to learn the basics of Kotlin. In this recording, you can watch as I let the IDE guide me, stumble through mistakes, and get help from viewers. You'll get to see how much better a good IDE can be than what we experience with Xcode.
Aside from learning Kotlin itself, I experienced two big things. First, it showed me that with good tooling, test-driven development is a nice way to learn a new language.
Second, I got to experience what it was like to do live coding on Twitch. This came about from talking with Ted Young, who broadcasts his test-driven coding nearly every day. Ted told me why he does it and what he gets out of it. This gave me the courage to jump in and give it a whirl. With only a 5-minute warning that I was going live, I didn't expect anyone to be watching. So it surprised me to have a couple of viewers jump in who helped guide me into Kotlin coding.
I don't expect folks to watch the full 2 hours of me stumbling along. But let me give you some tips on ways this recording could be helpful to you. …Even if you're a die-hard Swift programmer who would rather "be dead in a ditch" than learn Kotlin.
1. Increase Playback Speed
There's a fair bit of "dead air" where I'm sitting, thinking about what to do next. I recommend increasing the playback speed, even if you jump around and only watch a chapter or two.
If you've ever watched me code during a conference talk, what you saw was rehearsed. But in a live stream, you get to watch all my mistakes and fumbling around. I hope this reassures you that coding in a test-driven manner doesn't mean that everything goes smoothly.
2. Pick and Choose
I did some minimal editing to break the stream into chapters (and add an introduction). That way, you can look over the chapter titles to pick one or things that might interest you. Here's the breakdown:
- Intro
- Hello, Twitch!
- The Exercise: TDD Paint-by-Numbers
- Kotlin Tooling Puts Swift Tooling to Shame
- Much, Much Cleaner Test Names
- @Before (a.k.a. setUp) Still Matters in JUnit
- TDD Lessons from TCR: Commit Small Steps
- Test 1 …and Some Chat Room Activity
- Test 2 & Refactoring: “IntelliJ Knows Your Code Better than You Do”
- Test 3: The First Hard One Where I Dive into Kotlin
- Playing with IntelliJ Intentions to Explore Kotlin
- Test 4: Straightforward
- Test 5: Writing Ugly Code, Then Refactoring, Refactoring
- Test 6: First Refactor, Then Pass
- Test 7: Puzzling over Multiple Middle Names
- Looping to Build a String: Playing with Alternatives
- Test 8: Getting Tired, Refreshed by 5-Minute Break
- Test 9: IntelliJ Offers Suggestions Before I Ask
- Focusing on Readability (Naming Things Is Hard)
- Closing Thoughts
(On other screencasts, I hand-edit captions to help folks who can't hear. This also helps if your English isn't your first language. But I'm afraid doing that on a 2-hour recording isn't practical for me. You'll have to lean on YouTube's automatic transcription, and hope for the best.)
3. See What Good Tooling Makes Possible
Kotlin is a language invented by company that makes tools. So they focused on building good tooling in and around this language.
By contrast, Swift was invented by folks trying to solve language problems. The tooling is an add-on. This contrast is most obvious with Xcode. Even AppCode suffers from Swift's origins because the tool makers have had to bolt on their tooling from the outside.
So I encourage you to watch the chapters where I experience what it's like to have good tooling. If you know anyone at Apple who works on Swift or Xcode, please ask them to watch. I want folks to see what's possible so that we know where Swift is currently lacking.
Learning Kotlin shows what a good IDE makes possible. Swift/Xcode is currently lacking.
Follow Me on Twitch
Finally, I encourage you to follow me on Twitch. I don't know when I'll be streaming next. I don't know what it'll be about. But by following, you'll receive a notification when I go live. Then instead of watching a recording, you'll be able to interact directly with me through the chatbox.
And it's that interaction that makes this fun!
What would you like to see in an upcoming stream? Any particular coding? Q&A? Please share your ideas in the comments below.
Being an iOS and Android developer, I face this “truth” literally every day!
Sumit,
Oh I have questions for you! Would you agree that Kotlin tooling is better? I’m curious to learn more from others.
Also, if we get into iOS/Android, that’s something I have yet to explore. It gets us out of Jetbrains tooling into Google tooling. How would you compare the Android emulator to the iOS simulator?
I never felt Xcode as an IDE. It was always lacking very important features.
With IntelliJ, the IDE is always helping you write code better and faster. It feels like a breeze.
But, Xcode… always keeps coming in the way! It’s like Apple purposefully made it to make our life difficult!
And, allow me to disagree with your statement that, “Jetbrains was able to achieve it because Kotlin is their own language”. IntelliJ works as efficiently with Java as well. In fact, I have used Jetbrains IDEs for Php, JavaScript, and Python, and they all work great.
Xcode… was as bad with ObjC as it is with Swift…
Sumit, tell us how you REALLY feel! ?
I try to stick to AppCode as much as possible. (Sometimes this can cause problems on large projects, but I’m filing issues as they come up. One great thing about Jetbrains issue tracking is I can follow the progress of tickets I create! So unlike Apple.)
First, I’m an experiential learner. I had an ex who would learn a new city by taking the car and getting lost quite a few times. Hours later, he’d emerge…and have complete recall of where everything is.
I’m not *that* extreme, but that’s always been my approach: work until you hit a wall, then search for why. This is why TDD appeals to me so much.
I remember, back in old Mac days, I’d wanted to refactor a too-complex function. However, it was all working and I’d gotten the existing (before I was hired) leaks fixed. My manager deemed it “too risky,” and it still irritates me 25 years later. TDD would have made that risk vanish if we’d had all the cases set up properly. Of course, effective source control would have too, but that was 25 years ago.
Things are so much better now.
Thanks for sharing your stories, Deirdre.
In my “I don’t know what I’m doing, but maybe TDD can help” experience, it felt like the tests were those gutter bumpers you can put up for bowling. It didn’t mean I’d write good Kotlin code. But it gave me latitude within the bumpers.
Oh yeah, it defines the box you’re playing in.
One of the things I remember was having to figure out where a memory leak was happening with too few tools. Back then, you could actually see a map of the memory block by block, and when it got low, classic MacOS would push the relocatable blocks to one side like a curtain, and the allocations would start again.
Because breakpoints made the process too slow, I used audio for debugging, so it was a matter of listening to the pattern of sounds before the memory pressure hit.
I’m not sure how I’d write the tests for that now, but it’s something I’ve been pondering.
TDD doesn’t help with that sort of defect. I think I’ve written an after-the-fact test only once or twice on a memory problem, to make sure the problem didn’t come back. Something like, after we call this and it gets a chance to clean up, is the object still there?
Yes, exactly. It’s more one of those things where you wonder how you could have done better, right? Then again, we used the tools we had at the time, and they’re far better now.