Posts Tagged ‘Kotlin’
[KotlinConf2025] LangChain4j with Quarkus
In a collaboration between Red Hat and Twilio, Max Rydahl Andersen and Konstantin Pavlov presented an illuminating session on the powerful combination of LangChain4j and Quarkus for building AI-driven applications with Kotlin. The talk addressed the burgeoning demand for integrating artificial intelligence into modern software and the common difficulties developers encounter, such as complex setups and performance bottlenecks. By merging Kotlin’s expressive power, Quarkus’s rapid runtime, and LangChain4j’s AI capabilities, the presenters demonstrated a streamlined and effective solution for creating cutting-edge applications.
A Synergistic Approach to AI Integration
The core of the session focused on the seamless synergy between the three technologies. Andersen and Pavlov detailed how Kotlin’s idiomatic features simplify the development of AI workflows. They presented a compelling case for using LangChain4j, a versatile framework for building language model-based applications, within the Quarkus ecosystem. Quarkus, with its fast startup times and low memory footprint, proved to be an ideal runtime for these resource-intensive applications. The presenters walked through practical code samples, illustrating how to set up the environment, manage dependencies, and orchestrate AI tools efficiently. They emphasized that this integrated approach significantly reduces the friction typically associated with AI development, allowing engineers to focus on business logic rather than infrastructural challenges.
Enhancing Performance and Productivity
The talk also addressed the critical aspect of performance. The presenters demonstrated how the combination of LangChain4j and Quarkus enables the creation of high-performing, AI-powered applications. They discussed the importance of leveraging Quarkus’s native compilation capabilities, which can lead to dramatic improvements in startup time and resource utilization. Additionally, they touched on the ongoing work to optimize the Kotlin compiler’s interaction with the Quarkus build system. Andersen noted that while the current process is efficient, there are continuous efforts to further reduce build times and enhance developer productivity. This commitment to performance underscores the value of this tech stack for developers who need to build scalable and responsive AI solutions.
The Path Forward
Looking ahead, Andersen and Pavlov outlined the future roadmap for LangChain4j and its integration with Quarkus. They highlighted upcoming features, such as the native asynchronous API, which will provide enhanced support for Kotlin coroutines. While acknowledging the importance of coroutines for certain use cases, they also reminded the audience that traditional blocking and virtual threads remain perfectly viable and often preferred for a majority of applications. They also extended an open invitation to the community to contribute to the project, emphasizing that the development of these tools is a collaborative effort. The session concluded with a powerful message: this technology stack is not just about building applications; it’s about empowering developers to confidently tackle the next generation of AI-driven projects.
Links:
[KotlinConf2024] Kotlin Multiplatform Powers Google Workspace
At KotlinConf2024, Jason Parachoniak, a Google Workspace engineer, detailed Google’s shift from a Java-based multiplatform system to Kotlin Multiplatform (KMP), starting with Google Docs. For over a decade, Workspace has relied on shared code for consistency across platforms, like Gmail’s synchronization layer. Jason shared how KMP enhances this approach, leveraging Kotlin’s ecosystem for better performance and native interop. The talk highlighted lessons from the migration, focusing on build efficiency, runtime latency, and memory challenges, offering insights for large-scale KMP adoption.
Why Kotlin Multiplatform for Workspace
Google Workspace has long used multiplatform code to ensure consistency, such as identical email drafts across devices in Gmail or uniform document models in Docs. Jason explained that their Java-based system, using transpilers like J2ObjC, was effective but complex. KMP offers a modern alternative, allowing developers to write Kotlin code that compiles to native platforms, improving runtime performance and ecosystem integration. By targeting business logic—everything beyond the UI—Workspace ensures native-feel apps while sharing critical functionality, aligning with user expectations for productivity tools.
Google Docs: The Migration Testbed
The migration began with Google Docs, chosen for its heavily annotated codebase, which tracks build performance, latency, and memory usage. Jason described how Docs is rolling out on KMP, providing metrics to refine the Kotlin compiler and runtime. This controlled environment allowed Google to compare KMP against their legacy system, ensuring parity before expanding to other apps. Collaboration with JetBrains and the Android team has been key, with iterative improvements driven by real-world data, setting a foundation for broader Workspace adoption.
Tackling Build Performance
Build performance posed challenges, as Google’s Bazel-like system resembles clean builds, unlike Gradle’s incremental approach. Jason recounted a 10-minute build time increase after a Kotlin Native update optimized LLVM bitcode generation. While this improved binary size and speed, it slowed builds. Profiling revealed a slow LLVM pass, already fixed in a newer version. Google patched LLVM temporarily, reducing build times from 30 to 8 minutes, and is working with JetBrains to update Kotlin Native’s LLVM, prioritizing stability alongside the K2 compiler rollout.
Optimizing Runtime Latency
Runtime latency, critical for Workspace apps, required Kotlin Native garbage collection (GC) tweaks. Jason noted that JetBrains proactively adjusted GC before receiving Google’s metrics, but further heuristics were needed as latency issues emerged. String handling in the interop layer also caused bottlenecks, addressed with temporary workarounds. Google is designing long-term fixes with JetBrains, ensuring smooth performance across platforms. These efforts highlight KMP’s potential for high-performance apps, provided runtime challenges are systematically resolved through collaboration.
Addressing Memory Usage
Memory usage spikes were a surprise, particularly between iOS 15 and 16. Jason explained that iOS 16’s security-driven constant pool remapping marked Kotlin Native’s vtables as dirty, consuming megabytes of RAM. Google developed a heap dump tool generating HPROF files, compatible with IntelliJ’s Java heap analysis, to diagnose issues. This tool is being upstreamed to Kotlin Native’s runtime, enhancing debugging capabilities. These insights are guiding Google’s memory optimization strategy, ensuring KMP meets Workspace’s stringent performance requirements as the migration expands.
Links:
[KotlinConf2025] Closing Panel
The concluding panel of KotlinConf2025 offered a vibrant and candid discussion, serving as the capstone to the conference. The diverse group of experts from JetBrains, Netflix, and Google engaged in a wide-ranging dialogue, reflecting on the state of Kotlin, its evolution, and the path forward. They provided a unique blend of perspectives, from language design and backend development to mobile application architecture and developer experience. The conversation was an unfiltered look into the challenges and opportunities facing the Kotlin community, touching on everything from compiler performance to the future of multiplatform development.
The Language and its Future
A central theme of the discussion was the ongoing development of the Kotlin language itself. The panel members, including Simon from the K2 compiler team and Michael from language design, shared insights into the rigorous process of evolving Kotlin. They addressed questions about new language features and the careful balance between adding functionality and maintaining simplicity. A notable point of contention and discussion was the topic of coroutines and the broader asynchronous programming landscape. The experts debated the best practices for managing concurrency and how Kotlin’s native features are designed to simplify these complex tasks. There was a consensus that while new features are exciting, the primary focus remains on stability, performance, and enhancing the developer experience.
The State of Multiplatform Development
The conversation naturally shifted to Kotlin Multiplatform (KMP), which has become a cornerstone of the Kotlin ecosystem. The panelists explored the challenges and successes of building applications that run seamlessly across different platforms. Representatives from companies like Netflix and AWS, who are using KMP for large-scale projects, shared their experiences. They discussed the complexities of managing shared codebases, ensuring consistent performance, and maintaining a robust build system. The experts emphasized that while KMP offers immense benefits in terms of code reuse, it also requires a thoughtful approach to architecture and toolchain management. The panel concluded that KMP is a powerful tool, but its success depends on careful planning and a deep understanding of the underlying platforms.
Community and Ecosystem
Beyond the technical discussions, the panel also reflected on the health and vibrancy of the Kotlin community. A developer advocate, SA, and others spoke about the importance of fostering an inclusive environment and the role of the community in shaping the language. They highlighted the value of feedback from developers and the critical role it plays in guiding the direction of the language and its tooling. The discussion also touched upon the broader ecosystem, including the various libraries and frameworks that have emerged to support Kotlin development. The panel’s enthusiasm for the community was palpable, and they expressed optimism about Kotlin’s continued growth and adoption in the years to come.
Links:
[KotlinConf2025] The Life and Death of a Kotlin Native Object
The journey of an object within a computer’s memory is a topic that is often obscured from the everyday developer. In a highly insightful session, Troels Lund, a leader on the Kotlin/Native team at Google, delves into the intricacies of what transpires behind the scenes when an object is instantiated and subsequently discarded within the Kotlin/Native runtime. This detailed examination provides a compelling look at a subject that is usually managed automatically, demonstrating the sophisticated mechanisms at play to ensure efficient memory management and robust application performance.
The Inner Workings of the Runtime
Lund begins by exploring the foundational elements of the Kotlin/Native runtime, highlighting its role in bridging the gap between high-level Kotlin code and the native environment. The runtime is responsible for a variety of critical tasks, including memory layout, garbage collection, and managing object lifecycles. One of the central tenets of this system is its ability to handle memory allocation and deallocation with minimal developer intervention. The talk illustrates how an object’s structure is precisely defined in memory, a crucial step for both performance and predictability. This low-level perspective offered a new appreciation for the seamless operation that developers have come to expect.
A Deep Dive into Garbage Collection
The talk then progresses to the sophisticated mechanisms of garbage collection. A deep dive into the Kotlin/Native memory model reveals a system designed for both performance and concurrency. Lund describes the dual approach of a parallel mark and concurrent sweep and a concurrent mark and sweep. The parallel mark and concurrent sweep is designed to maximize throughput by parallelizing the marking phase, while the concurrent mark and sweep aims to minimize pause times by allowing the sweeping phase to happen alongside application execution. The session details how these processes identify and reclaim memory from objects that are no longer in use, preventing memory leaks and maintaining system stability. The discussion also touches upon weak references and their role in memory management. Lund explains how these references are cleared out in a timely manner, ensuring that objects that should be garbage-collected are not resurrected.
Final Thoughts on the Runtime
In his concluding remarks, Lund offers a final summary of the Kotlin/Native runtime. He reiterates that this is a snapshot of what is happening now, and that the details are subject to change over time as new features are added and existing ones are optimized. He emphasizes that the goal of the team is to ensure that the developer experience is as smooth and effortless as possible, with the intricate details of memory management handled transparently by the runtime. The session serves as a powerful reminder of the complex engineering that underpins the simplicity and elegance of the Kotlin language, particularly in its native context.
Links:
[KotlinConf2024] Revamping Kotlin’s Type System: A Vision
At KotlinConf2024, Ross Tate, a programming language researcher, exposed critical flaws in Kotlin’s type system, including undecidability and unsoundness, which can crash compilers or misclassify types. Collaborating with the Kotlin team, he proposed pragmatic restrictions to ensure reliability and introduced extensions like categorized union types for error handling. Ross shared a long-term strategy to make type checking sound, decidable, and extensible, inviting developers to shape Kotlin’s future through feedback, balancing theory with practical needs.
Uncovering Type System Flaws
Kotlin’s type system, while powerful, is flawed. Ross revealed its undecidability, where subtyping questions can encode Turing machines, causing unpredictable compiler behavior. This stems from Java’s similar issues, as proven by Ru Gregori’s research. Unsoundness is equally concerning—Ross demonstrated a program tricking the compiler into treating an Int as a String using type projections and nulls. These flaws, also present in Java and Scala, undermine reliability, making robust type checking a priority for Kotlin’s evolution.
The Dangers of Unsound Programs
Unsoundness risks memory corruption. Ross presented a fast integer-to-string converter that, without proper checks, could introduce vulnerabilities. Initially, Kotlin’s compiler rejected it, as Int isn’t a subtype of String. However, adding a magic configuration with existential type projections bypassed this safeguard, fooling the compiler. Adapted from Java and Scala examples, this highlights a shared problem. Ross stressed that revamping Kotlin involves eliminating such unintentional backdoors, ensuring only explicit casts compromise safety, preserving developer trust.
Type Inference Challenges
Type inference, vital for Kotlin’s usability, struggles with decomposition. Ross showed a tree class for sorting adjectives, which type-checks when whole but fails when split into smaller parts. The compiler couldn’t infer the branch type B, violating the principle that breaking programs into smaller units shouldn’t break type checking. Co-variance adjustments revealed a principal type (Nothing), but Java’s undecidable subtyping influenced Kotlin’s conservative design. Ross aims to fix this, ensuring inference supports modular, predictable codebases.
Pragmatic Restrictions for Decidability
To address undecidability, Ross proposed separating interfaces into “shapes” (type constraints, like Comparable) and “materials” (data types, like function interfaces). Analyzing 135 million lines of Java code, he found all interfaces fit one category, making subtyping decidable in practice. By embedding this pattern into Kotlin, type checking becomes reliable and efficient, running in polynomial time. This separation also improves usability, as hovering over a variable avoids irrelevant types like Comparable<*>, aligning with developer expectations.
Categorized Union Types for Errors
Ross previewed categorized union types, restricted to prevent exponential type-checking costs. Types are grouped into categories (e.g., Null, Any, Error), allowing unions only across categories, like T | NoSuchValue. This enables distinguishing custom errors from null, as shown in a lastOrError function. Operators like !. (propagate error), !: (replace error), and !! (throw exception) mirror nullable syntax, simplifying libraries. Q&A clarified errors remain manipulable values, enhancing flexibility without compromising efficiency.
Enhancing Error Handling
The proposed error system differentiates errors (values) from exceptions (control flow). Error classes include a throw method for conversion to exceptions, while Throwable subclasses form distinct categories, enabling multi-catch via union types. A try-catch variant infers the union of thrown types, supporting exhaustive checks with Java’s typed exceptions. This design, inspired by Rust’s result pattern, balances explicit error handling with backward compatibility, addressing interoperability concerns raised in Q&A about Java’s ecosystem.
Shaping Kotlin’s Future
Ross emphasized that these changes are experimental, requiring prototypes, trials, and community input. Challenges like name resolution and method overloading need strategies, and features must cohere. He invited feedback via issue KT-68296, especially on error naming (e.g., “Error” vs. “Sentinel”) to avoid Java confusion. The talk underscored Kotlin’s shift toward optimizing its own experience, even at the cost of some Java interop precision, ensuring a reliable, extensible type system for future developers.
Links:
[KotlinConf2025] Code Quality at Scale: Future Proof Your Android Codebase with KtLint and Detekt
Managing a large, multi-team codebase is a monumental task, especially when it has evolved over many years. Introducing architectural changes and maintaining consistency across autonomous teams adds another layer of complexity. In a comprehensive discussion, Tristan Hamilton, a distinguished member of the HubSpot team, presented a strategic approach to future-proofing Android codebases by leveraging static analysis tools like KtLint and Detekt.
Tristan began by framing the challenges inherent in a codebase that has grown and changed for over eight years. He emphasized that without robust systems, technical debt can accumulate, and architectural principles can erode as different teams introduce their own patterns. The solution, he proposed, lies in integrating automated guardrails directly into the continuous integration (CI) pipeline. This proactive approach ensures a consistent level of code quality and helps prevent the introduction of new technical debt.
He then delved into the specifics of two powerful static analysis tools: KtLint and Detekt. KtLint, as a code linter, focuses on enforcing consistent formatting and style, ensuring that the codebase adheres to a single, readable standard. Detekt, on the other hand, is a more powerful static analysis tool that goes beyond simple style checks. Tristan highlighted its ability to perform advanced analysis, including type resolution, which allows it to enforce architectural patterns and detect complex code smells that a simple linter might miss. He shared practical examples of how Detekt can be used to identify and refactor anti-patterns, such as excessive class size or complex methods, thereby improving the overall health of the codebase.
A significant part of the talk was dedicated to a specific, and crucial, application of these tools: safely enabling R8, the code shrinker and optimizer, in a multi-module Android application. The process is notoriously difficult and can often lead to runtime crashes if not handled correctly. Tristan showcased how custom Detekt rules could be created to enforce specific architectural principles at build time. For instance, a custom rule could ensure that certain classes are not obfuscated or that specific dependencies are correctly handled, effectively creating automated safety nets. This approach allowed the HubSpot team to gain confidence in their R8 configuration and ship with greater speed and reliability.
Tristan concluded by offering a set of key takeaways for developers and teams. He underscored the importance of moving beyond traditional static analysis and embracing tools that can codify architectural patterns. By automating the enforcement of these patterns, teams can ensure the integrity of their codebase, even as it grows and evolves. This strategy not only reduces technical debt but also prepares the codebase for future changes, including the integration of new technologies and methodologies, such as Large Language Model (LLM) generated code. It is a powerful method for building robust, maintainable, and future-ready software.
Links:
[KotlinConf2024] DataFrame: Kotlin’s Dynamic Data Handling
At KotlinConf2024, Roman Belov, JetBrains’ Kotlin Moods group leader, showcased Kotlin DataFrame, a versatile library for managing flat and hierarchical data. Designed for general developers, not just data scientists, DataFrame handles CSV, JSON, and object subgraphs, enabling seamless data transformation and visualization. Roman demonstrated its integration with Kotlin Notebook for prototyping and a compiler plugin for dynamic type inference, using a KotlinConf app backend as an example. This talk highlighted how DataFrame empowers developers to build robust, interactive data pipelines.
DataFrame: A Versatile Data Structure
Kotlin DataFrame redefines data handling for Kotlin developers. Roman explained that, unlike traditional data classes, DataFrame supports dynamic column manipulation, akin to Excel tables. It can read, write, and transform data from formats like CSV or JSON, making it ideal for both analytics and general projects. For a KotlinConf app, DataFrame processed session data from a REST API, allowing developers to filter, sort, and pivot data effortlessly, providing a flexible alternative to rigid data class structures.
Prototyping with Kotlin Notebook
Kotlin Notebook, a plugin for IntelliJ IDEA Ultimate, enhances DataFrame’s prototyping capabilities. Roman demonstrated creating a scratch file to fetch session data via Ktor Client. The notebook’s auto-completion for dependencies, like Ktor or DataFrame, simplifies setup, downloading the latest versions from Maven Central. Interactive tables display hierarchical data, and each code fragment updates variable types, enabling rapid experimentation. This environment suits developers iterating on ideas, offering a low-friction way to test data transformations before production.
Dynamic Type Inference in Action
DataFrame’s compiler plugin, built for the K2 compiler, introduces on-the-fly type inference. Roman showed how it analyzes a DataFrame’s schema during execution, generating extension properties for columns. For example, accessing a title column in a sessions DataFrame feels like using a property, with auto-completion for column names and types. This eliminates manual schema definitions, streamlining data wrangling. Though experimental, the plugin cached schemas efficiently, ensuring performance, as seen when filtering multiplatform talk descriptions.
Handling Hierarchical Data
DataFrame excels with hierarchical structures, unlike flat data classes. Roman illustrated this with nested JSON from the KotlinConf API, converting categories into a DataFrame with grouped columns. Developers can navigate sub-DataFrames within cells, mirroring data class nesting. For instance, a category’s items array became a sub-DataFrame, accessible via intuitive APIs. This capability supports complex data like object subgraphs, enabling developers to transform and analyze nested structures without cumbersome manual mappings.
Building a KotlinConf Schedule
Roman walked through a practical example: creating a daily schedule for KotlinConf. Starting with session data, he converted startsAt strings to LocalDateTime, filtered out service sessions, and joined room IDs with room names from another DataFrame. Sorting by start time and pivoting by room produced a clean schedule, with nulls replaced by empty strings. The resulting HTML table, generated directly in the notebook, showcased DataFrame’s ability to transform REST API data into user-friendly outputs, all with concise, readable code.
Visualizing Data with Kandy
DataFrame integrates with Kandy, JetBrains’ visualization library, to create charts. Roman demonstrated analyzing GitHub commits from the Kotlin repository, grouping them by week to plot commit counts and average message lengths. The resulting chart revealed trends, like steady growth potentially tied to CI improvements. Kandy’s simple API, paired with DataFrame’s data manipulation, makes visualization accessible. Roman encouraged exploring Kandy’s website for examples, highlighting its role in turning raw data into actionable insights.
DataFrame in Production
Moving DataFrame to production is straightforward. Roman showed copying notebook code into IntelliJ’s EAP version, importing the generated schema to access columns as properties. The compiler plugin evolves schemas dynamically, supporting operations like adding a room column and using it immediately. This approach minimizes boilerplate, as seen when serializing a schedule to JSON. Though the plugin is experimental, its integration with K2 ensures reliability, making DataFrame a practical choice for building scalable backend systems, from APIs to data pipelines.
Links:
[KotlinConf2025] Two Years with Kotlin Multiplatform: From Zero to 55% Shared Code
The journey to unified mobile applications is a complex one, fraught with technical and organizational challenges. Rodrigo Sicarelli, a staff software engineer at StoneCo, a leading Latin American fintech company, shared a compelling real-world account of his company’s two-year transition to Kotlin Multiplatform (KMP). This exploration revealed the strategic decisions, hurdles, and impressive achievements that led to a remarkable 55% code sharing across two large-scale mobile applications.
The initial challenge for StoneCo was to evaluate various cross-platform frameworks to find one that could balance the efficiency of code sharing with the critical need for a seamless user experience in the financial sector. Rodrigo detailed the exhaustive process of assessment and the ultimate decision to adopt KMP, a choice that promised to unify their mobile development efforts. A key part of the journey was the organizational shift, which involved training 130 mobile engineers to embrace a new paradigm. Rodrigo emphasized that this was not merely a technical migration but a cultural and educational one, fostering a collaborative spirit and promoting knowledge sharing across teams.
As the adoption matured, the teams faced a number of technical hurdles. One of the primary challenges was ensuring consistent data models and a unified network layer. Rodrigo outlined how they tackled this by consolidating data sources and creating a shared codebase for networking logic, which streamlined development and reduced errors. Another significant obstacle was the integration of KMP into their iOS CI/CD pipeline. He provided a clear explanation of how they overcame this by creating custom Gradle tasks and optimizing their build process, which dramatically improved build times. He also touched upon the importance of addressing the specific needs of iOS developers, particularly concerning the generation of idiomatic Swift APIs from the shared Kotlin code.
A major win for the team was the development of a custom Gradle plugin to manage Kotlin Multiplatform dependencies. This innovation was designed to solve a problem with exposing external libraries to Swift, where the linker would sometimes struggle with duplicate symbols. By adding annotations, the team was able to improve the linking process and reduce build times. This solution not only streamlined their internal workflow but is also planned for open-sourcing, showcasing StoneCo’s commitment to giving back to the community.
Rodrigo concluded by looking to the future, outlining a vision for a single, unified application repository that is user-segment-aware and built with Compose Multiplatform. This forward-looking approach demonstrates a long-term commitment to KMP and a desire to continue pushing the boundaries of shared code. His talk provided invaluable, actionable insights for any organization considering or already in the process of scaling Kotlin Multiplatform.
Links:
- StoneCo website
- Two Years with Kotlin Multiplatform: From Zero to 55% Shared Code | Rodrigo Sicarelli
[KotlinConf2025] Dependencies and Kotlin Native
The world of dependency management is often taken for granted in the JVM ecosystem. However, when venturing into the realm of Kotlin Native, the familiar comforts of JAR files and class loaders fade, giving way to a more intricate and challenging landscape. In his insightful talk, Tadeas Kriz, a senior Kotlin developer at Touchlab, demystified this complex topic, offering a detailed comparison between JVM and native dependency handling and providing practical solutions for common issues.
Tadeas began by drawing a clear distinction between the two worlds. The JVM handles the heavy lifting of linking and loading dependencies at runtime, a process that is largely transparent to the developer. In contrast, Kotlin Native produces a standalone binary, which means the developer must contend with the nuances of native linking and compilation. This fundamental difference introduces a new set of challenges, particularly for those accustomed to the JVM’s seamless “it just works” experience.
He delved into the specifics of native platforms, examining dependency management tools like CocoaPods and Swift Package Manager used on Apple platforms. By comparing their strengths and weaknesses, Tadeas provided valuable context for how Kotlin Multiplatform fits into this ecosystem. He underscored the importance of understanding the native build process, a step that is often abstracted away but is crucial for troubleshooting the cryptic errors that can arise when integrating dependencies. He emphasized that static linking is often the most reliable approach in Kotlin Native, offering a more predictable and robust solution.
A significant portion of the talk was dedicated to practical workarounds and tools to overcome these challenges. Tadeas introduced a key concept: cinterop bindings, which are used to interact with C libraries from Kotlin Native code. He explained how to handle dynamic and static libraries and provided guidance on navigating the complexities of header file inclusion and symbol visibility. He also highlighted the utility of specific tools and practices, such as meticulously heeding build warnings, as they often contain clues to underlying issues.
Tadeas also brought attention to Skie, an open-source tool he co-authored, which addresses a key pain point for developers: the quality of the Kotlin Multiplatform API exposed to Swift. He explained that Skie enhances the generated Swift API, making it more idiomatic and easier for iOS developers to work with. He positioned it as a valuable solution for teams looking to improve their development workflow and collaboration while waiting for future features like Swift export. His talk provided a comprehensive guide, arming developers with the knowledge and tools needed to navigate the complexities of dependencies in the Kotlin Native world with greater confidence and efficiency.
Links:
[KotlinConf2024] The Best Programmer I Know: Insights from KotlinConf2024
At KotlinConf2024, Daniel Terhorst-North shared a heartfelt reflection on the traits of exceptional programmers, drawing from his 30-year career and a colleague who embodies these qualities. Without a formal degree, this programmer excels by starting tasks, prioritizing outcomes, simplifying solutions, choosing tools wisely, and fostering team growth. Daniel’s narrative, blending personal anecdotes and practical advice, inspires developers to cultivate curiosity, resilience, and empathy while building impactful software.
Starting with Action
Great programmers dive into tasks without hesitation. Daniel recounted how his colleague tackles projects by starting anywhere, embracing the unknown. This “just start” mindset counters procrastination, which Daniel admits to masking as research. By iterating rapidly—trying, failing, and learning—programmers overcome perfectionism and ego. Daniel likened progress to navigating a grid city, moving stoplight to stoplight, accepting delays as part of the journey, ensuring steady advancement toward solutions.
Prioritizing Outcomes Over Code
Building products, not just code, defines effective programming. Daniel emphasized that emotional investment should focus on outcomes, not code, which is merely a means. The best programmers write minimal, high-quality code, holding no attachment to it. Studying the domain reveals user needs, as Daniel learned during a financial project where ignorance of CDOs led to unintended consequences. Observing users’ frustrations, like manual data entry, uncovers opportunities to eliminate friction, enhancing product value.
Simplifying the Complex
Exceptional programmers see through complexity to find simple solutions. Daniel shared a story of his colleague bypassing bloated Java web servers by writing a lean one from the HTTP spec. In another case, a team debating JSON libraries was guided to implement a simple interface for nine serialized objects, avoiding heavy dependencies. Writing clear documentation, like a streamlined README, drives “embarrassment-driven refactoring,” ensuring solutions remain concise and maintainable, solving only what’s necessary.
Choosing Tools for the Problem
Tool selection should prioritize the product, not team familiarity. Daniel recounted a team learning Scala to sketch code quickly, despite no prior experience, proving adaptability trumps comfort. He advocated for polyglot programming, using Advent of Code to learn Rust and Go, which broadened his problem-solving perspective. By minimizing cognitive distance between problem and solution, as Rich Hickey’s “Simple Made Easy” suggests, programmers select tools that evolve with project needs, ensuring flexibility.
Fostering Team Care
Great programmers uplift their teams. Daniel finds joy in pairing and teaching, inspired by an XKCD comic about the “lucky 10,000” who learn something new daily. He creates environments for learning, drawing from jiu-jitsu’s teaching-first philosophy. Sending teams home to rest, as Daniel advocates, boosts effectiveness, while assuming positive intent—per Virginia Satir’s family therapy principle—builds empathy, transforming conflicts into opportunities for collaboration and growth.
Building Psychological Safety
Psychological safety, per Amy Edmondson’s research, is vital for high-performing teams. Daniel explained that safe teams encourage saying “I don’t know,” seeking help, and disagreeing without fear. A study of surgical teams showed high performers report more errors, reflecting trust, not incompetence. In software, this translates to teams where questions spark learning, help fosters collaboration, and dissent drives improvement, creating dynamic, challenging environments that fuel innovation.
Growing as a Programmer
Personal growth sustains programming excellence. Daniel urged developers to stay current through communities, contribute actively, and remain skeptical of trends like AI hype. Practicing via challenges like Advent of Code sharpens skills, as Daniel found when switching languages mid-puzzle. Balancing work with physical activities, like running, and prioritizing rest prevents burnout. By embracing continual learning and kindness, programmers evolve, as Daniel’s colleague demonstrates, into impactful, resilient professionals.