Forem: Raul Arroyo

Coming Back to Kotlin: Building a Real App with KMP Part 3 — From Raw HTML to Native Content

Raul Arroyo — Wed, 25 Mar 2026 00:44:51 +0000

Part 3 — Parsing WordPress HTML and Enriching Embeds

WordPress posts arrive as raw HTML strings. A single post might contain paragraphs, headings, YouTube iframes, Spotify embeds, Instagram blockquotes, image galleries, internal post references, and ordered lists — all mixed together, none of it consistent.

You can't just dump that into a WebView and call it a day. Well, you could. But the result looks like a website inside an app, it doesn't respect your theme, dark mode breaks, fonts are wrong, and interactions feel foreign. For a magazine app where the reading experience is the whole point, that's not acceptable.

The approach: a custom HTML parser that converts raw WordPress HTML into a typed List<ContentPart> that Compose can render natively.

ContentPart — The Typed Model

The first thing to build is the sealed interface that represents every possible block of content:

sealed interface ContentPart {
    data class Text(val content: AnnotatedString) : ContentPart
    data class Heading(val content: AnnotatedString, val level: Int) : ContentPart
    data class Image(val url: String, val alt: String?) : ContentPart
    data class Gallery(val imageUrls: List<String>) : ContentPart
    data class Video(val thumbnailUrl: String, val videoUrl: String) : ContentPart
    data class Spotify(
        val embedUrl: String,
        val title: String? = null,
        val thumbnailUrl: String? = null
    ) : ContentPart
    data class InstagramPost(val url: String, val username: String?) : ContentPart
    data class InternalPost(val slug: String, val title: String?) : ContentPart
    data class UnorderedList(val items: List<AnnotatedString>) : ContentPart
    data class OrderedList(val items: List<AnnotatedString>) : ContentPart
    data class CallToAction(val text: String, val url: String) : ContentPart
    data class Divider : ContentPart
    data class Html(val content: String) : ContentPart
}

Html is the escape hatch — anything the parser doesn't recognize yet goes there. It renders as-is with a fallback composable. Over time, as new block types show up in the content, they get their own ContentPart subtype and a proper UI.

The Parser — Strategy Pattern

The parser uses a BlockHandler interface:

interface BlockHandler {
    fun canHandle(tagName: String): Boolean
    fun handle(tagName: String, content: String): List<ContentPart>
}

Each handler knows how to process one type of block. The main HtmlParser finds block-level tags with a regex, extracts the full block content (with a depth counter for nested tags), and routes to the right handler:

val blockRegex = Regex(
    "<(p|img|iframe|figure|hr|ul|ol|h[1-6])(?:\\s[^>]*)?>",
    RegexOption.IGNORE_CASE
)

The handlers are registered as a list and checked in order:

fun defaultHandlers(): List<BlockHandler> = listOf(
    DividerBlockHandler,
    ImageBlockHandler,
    TextBlockHandler,
    EmbedBlockHandler,
    CallToActionBlockHandler,
    ListBlockHandler
)

A KMP-specific gotcha

Kotlin's Regex on KMP doesn't support DOT_MATCHES_ALL as a RegexOption. On JVM you can use (?s) in the pattern or Pattern.DOTALL. In KMP the portable fix is replacing . with [\s\S] in any regex that needs to match across newlines. Worth knowing before you spend an hour wondering why your regex works in unit tests on JVM but silently fails on iOS.

The Tricky Cases

Most block types are straightforward — a <p> becomes ContentPart.Text, an <img> becomes ContentPart.Image, an <hr> becomes ContentPart.Divider. The interesting ones are the embeds.

YouTube — lazy loading

WordPress with the custom theme uses lazy loading on iframes. The actual URL isn't in src — it's in data-lazy-src:

<iframe src="about:blank" 
        data-lazy-src="https://www.youtube.com/embed/{videoId}">

Any image validation logic needs to filter out about:blank URLs or you'll end up with broken thumbnails. The EmbedBlockHandler checks data-lazy-src first, then falls back to src.

For YouTube we don't embed the player — we show a thumbnail with a play button that opens the YouTube app via a confirmation dialog. Clean, fast, no WebView required.

Spotify — oEmbed enrichment

Spotify embeds arrive as an iframe with just the embed URL. Not very exciting to look at as a card. But Spotify has a public oEmbed endpoint that returns the track/album/playlist title and thumbnail — no authentication required:

GET https://open.spotify.com/oembed?url={spotifyUrl}

The SpotifyContentPart composable fetches this data with a LaunchedEffect and shows a skeleton while it loads. The result is a card with the actual album art and track title — something worth tapping.

The decision of where to make this request was interesting. It could live in the ViewModel, pre-fetched for all Spotify parts before rendering. But that means waiting for N requests before showing anything. Instead, each SpotifyContentPart fetches its own data independently using koinInject<SpotifyService>() directly in the composable. The cards load progressively as you scroll.

Instagram — blockquote detection

Instagram blocks thumbnail URLs from third-party apps — or so I thought.
Instagram actually has a semi-public thumbnail URL pattern:

https://www.instagram.com/p/{shortcode}/media/?size=l

We extract the shortcode from the embed URL and attempt to load it with SubcomposeAsyncImage. If Instagram blocks the request (which it does inconsistently), the error slot shows a fallback placeholder with the Instagram gradient branding. If it loads — and it does load sometimes — you get the actual post image with the aspect ratio adjusted dynamically using onSuccess to read the painter's intrinsicSize.

onSuccess = { state ->
    val width = state.painter.intrinsicSize.width
    val height = state.painter.intrinsicSize.height
    if (width > 0 && height > 0) {
        imageAspectRatio = width / height
    }
}

The container height starts at 220.dp as a fallback and adjusts to the real aspect ratio once the image loads. Not perfect, but better than a static placeholder.

Internal post references

The magazine embeds links to related articles within post content using a custom WordPress block class: wp-block-embed-my-wp-site. The EmbedBlockHandler detects this and extracts the slug from the href:

if (content.contains("wp-block-embed-my-wp-site")) {
    val slug = extractSiteSlug(content) ?: return emptyList()
    val title = extractEmbedTitle(content)
    return listOf(ContentPart.InternalPost(slug = slug, title = title))
}

At render time, InternalPostContentPart resolves the slug to a post ID via the repository — first checking the local DB, then the API if not cached — and navigates to that post on tap using the AppNavigator singleton from Part 2.

Image Grouping

WordPress content frequently includes multiple consecutive images — a photo series from a concert, an event gallery. Rendering them one-by-one as full-width images takes forever to scroll through.

After parsing, the ViewModel runs a post-processing step that groups three or more consecutive ContentPart.Image items into a ContentPart.Gallery:

private fun groupConsecutiveImages(
    parts: List<ContentPart>,
    minCount: Int = 3
): List<ContentPart> {
    val result = mutableListOf<ContentPart>()
    var i = 0
    while (i < parts.size) {
        val part = parts[i]
        if (part is ContentPart.Image) {
            var j = i
            while (j < parts.size && parts[j] is ContentPart.Image) j++
            val count = j - i
            if (count >= minCount) {
                val images = parts.subList(i, j)
                    .filterIsInstance<ContentPart.Image>()
                    .mapNotNull { it.url }
                result.add(ContentPart.Gallery(imageUrls = images))
                i = j
            } else {
                repeat(count) { result.add(parts[i + it]) }
                i += count
            }
        } else {
            result.add(part)
            i++
        }
    }
    return result
}

The GalleryContentPart composable renders these with different layouts depending on count — 3 images get a "hero + two below" layout, 4 get a "large left + three stacked right" layout, and 5+ get a mosaic with a +N counter on the last tile. Tapping any image or the counter opens a full-screen gallery viewer with pinch-to-zoom and swipe navigation.

The Result

After parsing, a typical post produces something like:

ContentPart.Text("La cantante belga Angèle ha regresado...")
ContentPart.InstagramPost(url = "https://www.instagram.com/p/DVTyrbVCPXe/")
ContentPart.Text("El video musical, creado con (LA)HORDE...")
ContentPart.Video(thumbnailUrl = "...", videoUrl = "...")

Each type gets its own composable renderer. The LazyColumn in PostDetailContent iterates over the list and dispatches to the right component. No WebViews, no HTML rendering engines, no platform-specific workarounds — just Compose all the way down.

What's Next

In Part 4 we cover the UI layer — the PostHero component with the collapsible top bar, custom theming with Anton and Space Grotesk fonts, platform-specific transitions, and the Material3 shapes gotcha that will catch you off guard if you expect the theme to propagate automatically.

Stack: Kotlin 2.3.10 · Compose Multiplatform 1.10.2 · Ktor 3.4.1 · SQLDelight 2.3.1 · Koin 4.1.1

Building the Architecture in KMP: Data Flow, MVI, and Hard Decisions

Raul Arroyo — Fri, 20 Mar 2026 01:07:12 +0000

Part 2 — Architecture, MVI, and the Offline-First Decision

In Part 1 I wrote about the stack and the first walls — library compatibility, Navigation3 bugs, Coil 3 differences. Now we get into the decisions that shaped how the whole app is structured.

Fair warning: this post has opinions. Architecture is one of those topics where everyone has a preferred approach, and mine was shaped by years of Android development followed by three years of Flutter. Your mileage may vary.

The Overall Structure

I'm following a simplified Clean Architecture. Not strict by the book, but principled enough that I can navigate the codebase without thinking too hard about where things live:

data/
  remote/
    model/       ← DTOs — what the API returns
    service/     ← Ktor clients (WordPress, Spotify)
    mapper/      ← DTO → Entity, Entity → Domain
  repository/    ← PostRepository — single source of truth
domain/
  model/         ← PostDetail, PostSummary, ContentPart
ui/
  screens/       ← ViewModels + Composables
  components/    ← Shared UI components
  navigation/    ← Navigation3 setup
  theme/         ← Colors, typography, shapes

The key constraint I set for myself: the UI layer never talks to the network directly. Everything goes through the repository, and the repository always reads from the database. The network is just a way to keep the database up to date.

Two Domain Models Instead of One

Early on I had a single Post model that tried to serve both the list view and the detail view. That doesn't scale well. The list needs almost nothing — title, excerpt, image, category. The detail needs author info, content, tags, related posts. Cramming those into one model means either always fetching too much or constantly dealing with nullable fields that "don't apply here."

I split them:

// For lists — lightweight, fast to load from DB
data class PostSummary(
    val id: Int,
    val title: String,
    val excerpt: String,
    val imageUrl: String?,
    val categoryName: String?,
    val isSaved: Boolean
)

// For the detail screen — everything we need
data class PostDetail(
    val id: Int,
    val title: String,
    val content: String,
    val imageUrl: String?,
    val categoryName: String?,
    val categoryId: Int?,
    val author: Author?,
    val date: String?,
    val slug: String?,
    val tags: List<String>,
    val tagIds: List<Int>,
    val isSaved: Boolean
)

One thing worth noting: PostDetail has both tags (the display names, like "Vive Latino") and tagIds (the WordPress IDs, like [38763, 1032]). The names come from the API's embedded _embedded.wp:term data. The IDs come from the top-level tags array. We need both — names for display, IDs for querying related posts.

Also notice that PostDetail has content as a raw string, but we never show it directly. It gets parsed into List<ContentPart> in the ViewModel before reaching the UI. More on the parser in Part 3.

The Data Flow

WordPress API (Ktor)
    ↓
WordpressPostDto
    ↓  toEntity()
PostEntity (SQLDelight DB)
    ↓  toPostSummary() / toPostDetail()
Domain Model
    ↓
ViewModel → UI

Every piece of data touches the database. The API is the source of new data. The database is the source of truth for the UI. This gives you offline support for free — if the API fails, you still render cached content.

The mapper layer is split into two files: WordpressPostDtoMapper.kt for DTO → Entity (data layer concern), and PostEntityMapper.kt for Entity → Domain (connecting the data layer to the domain). Each file has one job.

Offline-First Sync

The WordPress REST API has a modified_after parameter that returns only posts modified since a given timestamp. Combined with SQLDelight's ability to query MAX(lastModified), incremental sync becomes straightforward:

suspend fun syncPosts() = withContext(Dispatchers.IO) {
    val latestModified = queries.getLatestModifiedDate().executeAsOneOrNull()?.MAX
    val latestDate = queries.getLatestDate().executeAsOneOrNull()?.MAX

    if (latestModified == null || latestDate == null) {
        // Empty DB — initial download
        val posts = api.getPosts(perPage = 50)
        savePosts(posts)
    } else {
        // Incremental — only what changed since last sync
        val newPosts = api.getPosts(
            after = latestDate,
            modifiedAfter = latestModified
        )
        if (newPosts.isNotEmpty()) savePosts(newPosts)
    }
}

First launch: 50 posts. Every subsequent launch: only what changed. Fast, bandwidth-efficient, and the UI always has something to show even offline.

One gotcha: WordPress's modified_after parameter is not widely documented and the naming is slightly inconsistent across WordPress versions. Test it against your actual endpoint before trusting it.

MVI for Screen State

I've always used MVVM. It's what the Android documentation pushes, it's what most tutorials use, and honestly it works fine for most apps. But MVI has been getting a lot of attention lately — and for good reason. The unidirectional data flow, the explicit state modeling, the clear separation between what the user does and what the UI shows — it all clicks when you see it in action.

This project felt like the right place to try it properly. Not because MVVM would have failed here, but because I wanted to understand MVI from the inside, not just from blog posts.

The pattern maps cleanly to KMP ViewModels.

Each screen has three things:

Intent — what the user can do:

sealed interface PostDetailIntent {
    data class LoadPost(val postId: Int) : PostDetailIntent
    data class ToggleSaved(val postId: Int, val current: Boolean) : PostDetailIntent
    data class OpenGallery(val imageUrls: List<String>, val initialIndex: Int) : PostDetailIntent
}

State — what the UI renders:

sealed interface PostDetailState {
    data object Loading : PostDetailState
    data class Success(
        val postDetail: PostDetail,
        val parts: List<ContentPart>,
        val imageUrls: List<String>,
        val isSaved: Boolean,
        val relatedPosts: List<PostSummary> = emptyList()
    ) : PostDetailState
    data class Error(val error: Error) : PostDetailState
}

Effect — one-time events that don't belong in state:

sealed interface PostDetailEffect {
    data class ShowError(val error: Error) : PostDetailEffect
}

The ViewModel exposes a StateFlow<PostDetailState> for state and a Channel<PostDetailEffect> for effects. Why Channel and not SharedFlow for effects? Because SharedFlow can drop events if the collector isn't active at the moment of emission. Channel buffers them. For a snackbar that should appear exactly once, that matters.

class PostDetailViewModel(
    private val repository: PostRepository,
    private val htmlParser: HtmlParser,
    private val navigator: AppNavigator
) : ViewModel() {

    private val _state = MutableStateFlow<PostDetailState>(PostDetailState.Loading)
    val state: StateFlow<PostDetailState> = _state.asStateFlow()

    private val _effects = Channel<PostDetailEffect>(Channel.BUFFERED)
    val effects = _effects.receiveAsFlow()

    fun onIntent(intent: PostDetailIntent) {
        when (intent) {
            is PostDetailIntent.LoadPost -> loadPost(intent.postId)
            is PostDetailIntent.ToggleSaved -> toggleSaved(intent.postId, intent.current)
            is PostDetailIntent.OpenGallery -> navigator.navigateToGallery(
                intent.imageUrls, intent.initialIndex
            )
        }
    }
}

One Kotlin-specific gotcha worth mentioning: state comes from collectAsState() in Compose, which returns a delegated property. Smart casts don't work on delegated properties. This means you can't write if (state is PostDetailState.Success) { state.postDetail } — the compiler won't smart-cast state inside the branch. The fix is a local variable:

val currentState = state  // local variable — smart cast works here
when (currentState) {
    is PostDetailState.Success -> { currentState.postDetail }
    // ...
}

A small thing that can cost 20 minutes of confusion if you've never hit it before.

Navigation as a Singleton

One non-obvious decision: AppNavigator is a singleton in Koin. Not a scoped dependency, not passed through the composable tree — a single instance that any ViewModel or Composable can inject.

class AppNavigator {
    private var backStack: MutableList<NavKey>? = null

    fun attach(backStack: MutableList<NavKey>) {
        this.backStack = backStack
    }

    fun navigateToPost(postId: Int) {
        backStack?.add(AppRoute.PostDetail(postId))
    }

    fun navigateToGallery(imageUrls: List<String>, initialIndex: Int) {
        val json = Json.encodeToString(imageUrls)
        backStack?.add(AppRoute.ImageGallery(json, initialIndex))
    }
}

This means a component like InternalPostContentPart — which renders a "Read also" card inside a post's content — can navigate to another post without needing to bubble a callback up through five layers of composables. It just injects the navigator directly:

@Composable
fun InternalPostContentPart(part: ContentPart.InternalPost) {
    val repository = koinInject<PostRepository>()
    val navigator = koinInject<AppNavigator>()
    // ...
    Card(onClick = { postId?.let { navigator.navigateToPost(it) } }) { ... }
}

Whether this is "clean" is debatable. But it's pragmatic, and in a KMP project where threading the callback through shared composables gets complicated, the singleton approach saves real complexity.

What's Next

In Part 3 we get into the most technically interesting part of the project: the custom HTML parser that turns raw WordPress content into typed ContentPart objects that Compose can render. WordPress posts contain a mix of paragraphs, headings, YouTube embeds, Spotify iframes, Instagram blockquotes, image galleries, and internal post references — none of it consistent, all of it needing different UI treatment.

Stack: Kotlin 2.3.10 · Compose Multiplatform 1.10.2 · Ktor 3.4.1 · SQLDelight 2.3.1 · Koin 4.1.1

I Came Back to Kotlin for KMP — Here’s What Broke First

Raul Arroyo — Thu, 19 Mar 2026 05:53:31 +0000

Part 1 — Why KMP, Why Now, and the First Walls

I've been building mobile apps since 2011. Java with Eclipse, back when ADT was the only game in town and a simple ListView took half a day to get right. Then Kotlin came along and everything got better. Then Flutter came along and I spent the last three years living in Dart land — and honestly, it was great. But something kept pulling me back.

Late last week I decided to come back to Kotlin. Not for a side project or a tutorial — for something real. I collaborate with a music magazine that had just updated their WordPress backend and refreshed their theme. A working REST API, fresh content, a product I actually care about. It was the perfect excuse to dive into Kotlin Multiplatform.

I'd been watching KMP from a distance for years. It always seemed almost ready. Then in late 2023 it went stable, the tooling caught up, and the library ecosystem started filling in. The timing finally felt right.

This is the first post in a series documenting what I'm building and everything I'm learning along the way — the good decisions, the bad ones, and the things that just flat out broke.

The Pitch

The project is a reader app backed by a WordPress REST API — posts, authors, categories, tags, embeds. Nothing exotic on the backend side. The interesting part is entirely in the client.

The bet I'm making: Compose Multiplatform for the entire UI, not just shared business logic. One codebase for every screen on Android and iOS. That's a significant commitment compared to the typical "shared ViewModel, native UI" approach — but coming from Flutter, where you do exactly this, it feels natural. And for someone working alone, eliminating the context switch between two UI stacks is worth a lot.

Here's the full stack:

[versions]
kotlin = "2.3.10"
compose-multiplatform = "1.10.2"
ktor = "3.4.1"
sqldelight = "2.3.1"
koin = "4.1.1"
coil = "3.4.0"
navigation3 = "1.0.0-alpha06"

Each of these deserves its own explanation, because nothing here was obvious.

Why Not Room?

The first real decision was local storage. Coming from Android, Room is the obvious choice — I've used it for years. But Room's KMP support is still marked experimental, and on iOS in particular it can be fragile.

I went with SQLDelight instead. It's been KMP-native from the start. You write plain SQL, it generates fully type-safe Kotlin query functions and a data class for each table. Any mismatch between your schema and your code is a compile error — not a runtime crash at 2am.

The tradeoff is that you lose the annotation-based convenience of Room. But the result is surprisingly clean:

CREATE TABLE postEntity (
    id INTEGER NOT NULL PRIMARY KEY,
    title TEXT NOT NULL,
    excerpt TEXT NOT NULL,
    content TEXT NOT NULL,
    imageUrl TEXT,
    categoryName TEXT,
    categoryId INTEGER,
    slug TEXT,
    tags TEXT,
    isSaved INTEGER AS kotlin.Boolean NOT NULL DEFAULT 0,
    lastModified TEXT NOT NULL
);

selectPostById:
SELECT * FROM postEntity WHERE id = ?;

selectPostBySlug:
SELECT * FROM postEntity WHERE slug = ?;

SQLDelight generates a PostEntity data class and a selectPostById(id: Long): Query<PostEntity> function from this. You call it like normal Kotlin. Adding a column means updating the SQL — and the compiler tells you everywhere that needs to change.

Navigation3 — Alpha Is Alpha

For navigation I went with Navigation3, Jetbrains' new navigation library for Compose Multiplatform. At 1.0.0-alpha06 it's still rough around the edges.

The most painful bug I hit early: double-tapping the back button crashes the app. The backstack empties completely and Navigation3 throws trying to display nothing. The fix ended up being a simple guard:

val isNavigating = remember { mutableStateOf(false) }

fun safeBack() {
    if (!isNavigating.value && backStack.size > 1) {
        isNavigating.value = true
        backStack.removeLastOrNull()
        isNavigating.value = false
    }
}

Not elegant. But it works, and until the library stabilizes it's the pragmatic solution.

Coil, Koin, and the Details

Coil 3 introduced LocalPlatformContext for KMP — replacing Android's LocalContext. If you copy-paste Coil 2 code into a KMP project, images just don't load on iOS with no clear error. The fix is one line, but finding it costs time:

// This is how you do it in KMP — not LocalContext.current
ImageRequest.Builder(LocalPlatformContext.current)
    .data(url)
    .crossfade(true)
    .build()

Koin 4 initializes differently per platform. On Android you call startKoin in Application.onCreate(). On iOS you expose an initKoin() function and call it from Swift before the first Compose frame. The gotcha that bit me: KoinApplicationAlreadyStartedException. If Koin gets initialized twice — easy to do when juggling Android Application classes and iOS entry points — the app crashes immediately on launch with a confusing error message.

The `libs.versions.toml` Tax

This one isn't unique to KMP but it cost me real time. The libs.versions.toml file has a specific structure — [versions], [libraries], [plugins] — and Gradle's configuration cache is unforgiving about mistakes. I had library declarations mixed into the [versions] block and the error message pointed to something completely unrelated. The fix was formatting. The lesson was to read the TOML spec carefully upfront.

Coming from Flutter

One thing I didn't expect: the mental model shift from Flutter to Compose Multiplatform is smaller than I thought. Both are declarative UI frameworks with a component tree and reactive state. The Dart-to-Kotlin switch is almost a relief — I'm back in a language I know deeply, with IDE support that actually works.

What's different is the platform integration story. Flutter abstracts away the platform almost completely. KMP lets you go as native as you want, which is both powerful and occasionally annoying. Platform channels become expect/actual declarations. The splash screen, share functionality, and back gesture all need platform-specific handling that Flutter would paper over for you.

Whether that's a feature or a bug depends on what you're building. For an app that needs to feel native on both platforms, it's a feature.

What's Next

In Part 2 we'll get into the architecture — why we split posts into two domain models (PostSummary and PostDetail), how the data flows from the WordPress API through SQLDelight to the UI, and how MVI fits into a KMP ViewModel.

Stack: Kotlin 2.3.10 · Compose Multiplatform 1.10.2 · Ktor 3.4.1 · SQLDelight 2.3.1 · Koin 4.1.1 · Coil 3.4.0 · Navigation3 1.0.0-alpha06

Thoughts?

If you're exploring Kotlin Multiplatform right now, I'm curious — what’s been your biggest friction point so far?

Have you tried going full Compose Multiplatform for UI, or are you sticking to shared logic only?

Drop a comment, I'd love to compare notes (and maybe avoid a few future headaches).

Don't Lose the Spark: Keeping Your Coding Passion Alive in a Leadership Role

Raul Arroyo — Fri, 05 Apr 2024 06:15:20 +0000

Remember the thrill of seeing your first line of code come to life? That feeling of creation and problem-solving is what hooked me on software development for over 10 years. During all this time, I have had the opportunity to work on a huge ammount of projects and bussinness, for both small start-ups and big companies in various industries and using different technologies. Along the path, I have had the pleasure of meeting amazing people, learning a lot, and tackling obstacles that have contributed to my personal and professional path.

Enthusiasm and discovery.

My first projects involved building videogames from scratch, interact with motion sensors, create lots of eyecandy pages. Each line of code I wrote unlocked new possibilities, and the excitement of seeing it all come together was incredible. Every project was an escapade to learn new things as well as discover unexplored technology. It was exhilarating for me to be part of competent teams working alongside other developers towards making products for people's pleasure or use.

I remember how exciting it felt when what I built started being useful and users were happy about it. It is so satisfying realizing that my code actually matters to individuals' lives. This makes your work feel like second nature since you are actively participating in something bigger.

However, as time went by routine set in. Projects became more monotonous while tasks became repetitive. The learning curve flattened out and the initial enthusiasm wilted away. The sense of fulfilment I previously experienced upon finishing a project waned eventually giving way to emptiness and desolation.

The aspiration of the eternal developer.

From the very start, my vision was clear: to embody the essence of an eternal developer. To exist as a consistent entity, engrossed in a continual stream of code, accomplishing tasks in succession, without pause.

I envisioned myself laboring ceaselessly, mastering the complexities of code and resolving issues with precise accuracy. My objective was to evolve into a development powerhouse, adept at transforming any concept into a tangible manifestation. Nevertheless, the harsh reality soon became apparent.

A new challenge arises: managing groups of developers.

As my skills grew, so did my desire to contribute in a different way. Leading development teams became the next frontier for me, but it wasn't without its hurdles.

This transition, though exciting, can be a minefield for those who are unprepared, like me. Many talented programmers struggle initially in this new role. The main reason is that technical skills, while essential, are not enough to lead a team. A completely new set of habilities is required, a shift in focus that many are not ready to make.

What makes leading development teams so challenging?

Motivating a team with diverse personalities was initially tough. I learned to tailor my communication style and celebrate individual strengths

Managing different personalities is crucial for effective leadership.
Understanding each developer's unique work style, motivations, and preferences is essential for bringing out the best in each team member.
Clear and effective communication is vital for the success of any team. A leader must be able to clearly communicate goals, inspire the team, and address conflicts efficiently.
Delegating responsibilities is a key aspect of leadership. A leader cannot handle everything on their own and must learn to delegate tasks effectively, while trusting their team to complete them.
Motivating and inspiring the team, especially during challenging times, is a crucial skill for a leader. They must be able to keep their team motivated and engaged to achieve success.

Becoming the leader of development teams is a major accomplishment. Yet, this promotion comes with a harsh truth: you start to drift away from hands-on coding. The passion you once had for coding begins to fade, causing feelings of disappointment and a lack of drive.

How do you keep your love for software development alive

The pull of hands-on coding can be strong, even when you're leading a development team. Here are some strategies I used to keep myself connected to the code and the joy of creation:

Discover fresh methods to engage with coding

Engage in open source initiatives: Allocate time to contribute to projects that pique your interest. This will keep you aware of the newest technologies and techniques, and provide the chance to collaborate with other skilled developers.
Guide fellow developers: Share your expertise with novice programmers. This serves as a fantastic method to maintain your connection to coding and assist others in advancing their careers.
Stay on top with current trends: Stay informed by reading software development blogs, articles, and books. Attend industry conferences and events. Keeping up with the latest technologies will keep you motivated and on top.
Carve Out "Scratch Pad" Time: Scheduling dedicated time for personal coding projects, even if it was just a few hours a week, proved to be crucial. These projects allowed me to experiment with new libraries, frameworks, and coding paradigms, keeping my coding skills sharp and reigniting the spark of creative problem-solving.

Understand the importance of your role

Remember your role as a leader: it plays a crucial part in the team's success. Your choices and leadership style have a significant influence on the quality of work produced, the team's efficiency, and the satisfaction of customers.
Celebrate the team's achievements: When the team accomplishes its goals, take the time to acknowledge and celebrate the effort put in by each individual. This not only boosts morale but also keeps the team driven and engaged.
Keep your focus on the overarching goal: Don't lose sight of the primary objective in software development: creating products that are not only functional but also improve the lives of those who use them.

Achieving a balance:

One must strike a harmonious balance between leadership duties and coding enthusiasm. Seek chances to remain engaged in software development, even if it entails a reduced level of involvement.
Do not hesitate to assign tasks to others. You are not obligated to handle everything independently. Have confidence in your team and allot responsibilities to individuals, trust that they have the necessary skills and expertise.
Prioritize your mental and physical well-being. Stress and fatigue often afflict team leaders. Ensure you take periodic breaks, engage in physical activity and get enough rest.

Don't let your love for software development fade as you transition into a leadership role. There are plenty of ways to stay involved with coding, even if you're not actively writing lines of code every single day. As a leader, your actions have a big influence on the team's achievements.

Aim to be the kind of leader you've always admired
All the while balancing your leadership duties and your coding passion.

Becoming a software developer is not a straightforward process. It involves exciting findings, the joy of building something, and the expected hurdles of progress. As you progress in your career, keep in mind that the same initial excitement that got you into coding is still present.

Being a leader in software development allows you to use your technical skills to support and motivate others. It's all about creating a cooperative space where imagination flourishes, and where your direction helps a team accomplish extraordinary feats.

Keep the passion for coding alive! Being a leader is very fulfilling. Balancing between management and creativity is a valuable journey. Embrace new challenges, fuel your coding spirit with the mentioned strategies, and most importantly, lead with the same excitement for innovation that initially attracted you to coding.

The world of software development is always changing, and your leadership will influence the future. As you motivate others, don't forget to inspire yourself as well. The journey never stops!

Forem: Raul Arroyo

Coming Back to Kotlin: Building a Real App with KMP Part 3 — From Raw HTML to Native Content

Part 3 — Parsing WordPress HTML and Enriching Embeds

ContentPart — The Typed Model

The Parser — Strategy Pattern

A KMP-specific gotcha

The Tricky Cases

YouTube — lazy loading

Spotify — oEmbed enrichment

Instagram — blockquote detection

Internal post references

Image Grouping

The Result

What's Next

Building the Architecture in KMP: Data Flow, MVI, and Hard Decisions

Part 2 — Architecture, MVI, and the Offline-First Decision

The Overall Structure

Two Domain Models Instead of One

The Data Flow

Offline-First Sync

MVI for Screen State

Navigation as a Singleton

What's Next

I Came Back to Kotlin for KMP — Here’s What Broke First

Part 1 — Why KMP, Why Now, and the First Walls

The Pitch

Why Not Room?

Navigation3 — Alpha Is Alpha

Coil, Koin, and the Details

The libs.versions.toml Tax

Coming from Flutter

What's Next

Thoughts?

Don't Lose the Spark: Keeping Your Coding Passion Alive in a Leadership Role

Enthusiasm and discovery.

The aspiration of the eternal developer.

A new challenge arises: managing groups of developers.

How do you keep your love for software development alive

Discover fresh methods to engage with coding

Understand the importance of your role

Achieving a balance:

The `libs.versions.toml` Tax