> system online - lscythe - android engineer - jakarta, id - available for work
> lscythe.3d

lscythe_

android engineer / jakarta, id

stackkotlin / compose / kmp
employernocturn (fintech)
exp6 years
statusavailable
> about / lscythe

i'm lscythe. i build android apps for a living and break them in my spare time.

based in jakarta. six years into this, mostly on the android side, currently at nocturn - a fintech startup where i work on the mobile platform team. we're building the kind of infrastructure that most companies don't think about until something breaks at 2am during a payment flow.

my work sits at the intersection of how apps are architected and how they actually behave at runtime. those two things are rarely the same. most of what i write here is about the gap between them.


what i actually do

at nocturn, i own the android platform layer - build system, modularization strategy, shared component libraries, and the CI pipeline that keeps everything from falling apart. i spend a disproportionate amount of time in Gradle and i have strong opinions about it.

day to day: kotlin multiplatform experiments, compose UI, coroutines, and whatever Gradle is doing wrong this week.

i care a lot about build times. not as a vanity metric but because slow builds make teams ship slower, cut corners more, and write fewer tests. it's a product problem dressed up as a tooling problem.


current stack

  • kotlin - everything. if it's not kotlin i'm suspicious of it.
  • compose - ui layer, with a healthy distrust of stability annotations
  • kmp - actively migrating shared logic out of the android module
  • hilt - for now. the jury is still out.
  • room - still. yes, still.
  • gradle kotlin dsl - groovy is deprecated in my mind
  • github actions + gradle build cache - remote caching changed my life more than any architecture pattern

how i work

i write things down before i build them. not specs - more like thinking out loud. a rough document explaining why a decision makes sense forces me to find the holes before the code does.

i prefer boring solutions. kmp didn't become interesting to me because it was new; it became interesting when i realized i could delete two identical data-layer implementations. that's the whole pitch.

i don't use ai to write code for me but i do use it to explain what i'm looking at. there's a difference.


writing

occasional. when i have something that bothers me enough to spend a weekend on it. most of what ends up here started as a comment in a code review that got too long.


contact