AI translation
Last autumn, on a whim, I opened the code for an app that I had left untouched for about two years. There was no particular reason. It was just a feeling of "maybe it's time to fix a few things." But when I started reading the first file, I found myself looking away from the screen. What was there was not just code...
Enjoyed this article?
Support Lily
Last autumn, on a whim, I opened the code for an app I had left untouched for about two years. There was no particular reason. It was just a feeling of "maybe I should fix a few things soon." But when I started reading the first file, I found myself looking away from the screen. What was there wasn't just code.
The me from back then was there. The wavering of my judgment, the anxiety, the faint hope that someone might see it—all of it remained in its original form. Things I never wrote in my diary were written in the code. I'd like to talk about that today.
A diary requires the intention to write. But code is something you can't help but write. If you want to build a feature, you have no choice but to write something. That's why "the decisions of that day" are inevitably etched into it.
The first thing I noticed while reading the file was how defensive the variable names were. Names that seemed like they might make sense but didn't, comments mixed with "probably" and "I think" in parentheses. I immediately understood: "I wasn't confident it would work properly." If I had been confident, I would have written it more simply.
I wouldn't write it this way now, but back then I couldn't help but write it. Every time I opened the file, traces of that appeared.
Looking at the app's structure, there were clear signs of things stacked together "for now."
Processing that should have been consolidated in one place was scattered all over. Code I wrote intending to "fix later" was released as-is, and two years later it's still running the same way.
At first, I felt embarrassed. But as I read on, a different emotion emerged.
I was doing my best back then, I thought.
The way it was scattered was the very embodiment of pre-deadline panic. Not "release after perfecting it," but "I have to get something working out there"—that pressure was written directly into the code's structure. Rather than blame myself, I felt nostalgic.
It wasn't just embarrassing things.
There was a screen that had been carefully made even though it was unclear if anyone would use it. The error messages were written in kind words, and I could tell: "When someone gets stuck here, I really wanted to help them." On that screen that almost no one would ever see, the me from back then had genuinely put care into it.
On the statistics screen, without even checking if anyone would use it, detailed items were carefully laid out. "There might be someone who uses it this way"—that expectation had become a feature.
Code was a product, but also a storage place for the hope that "it might help someone."
As you continue with personal projects, your feelings gradually become more practical. "Is this feature really necessary?" "Is it worth the time?" Those kinds of questions keep increasing. That's not necessarily bad, but somewhere along the way the initial joy fades.
But in that code, there was a feeling that came before such calculations. "This would definitely be convenient," "This interaction would feel good"—traces of pure curiosity.
Reading that made me breathe a little easier.
To be honest, there were features I deleted that no one ever used.
I was very excited when making them. I wrote out ideas in a notebook, even sketched the screen layout by hand, and spent two weeks implementing. In the three months after release, according to the numbers, not a single user touched that feature.
When I made the next version, I quietly removed it.
At the time, I felt like "I wasted time." But when I saw that feature in the old code, it became endearing somehow. It wasn't used, but because of those two weeks, I'm certain the design of the next feature got a little better. I won't say it wasn't a failure. But it wasn't wasted either.
In the context of personal projects, numbers like "sold/didn't sell" and "got views/didn't get views" stand out. Post on X and the engagement becomes visible.
But in the code, there are records that don't show up in numbers. Traces of trial and error, marks where I changed direction, carefully written error handling, feelings poured into screens no one would see. No one sees it, but it's definitely there.
When you only look at results, it feels like your own footsteps disappear. But code remembers.
Reading old code, I noticed one more thing.
The me from back then never thought I'd read this again. That's why it remained in its raw state. But now I've started thinking, "What will I feel when I read this two years from now?"
I'm not doing anything special. I've just started writing commit messages a little more carefully. Not just "fix" or "update," but adding one line about "why I did this." I'm not adding more documentation or detailed comments—just leaving behind the fact that "this decision had a reason."
That alone becomes a letter to my future self.
Reading your own code two years later and understanding "oh, I was thinking about this back then" is simply a joy.
Even if writing a diary feels like a chore, you can't help but write code. So mixing in a little "emotional context" isn't that difficult. Before pursuing technical correctness, I write in a way that conveys "what was I thinking back then?" That's become a quiet but important habit for me now.
I used to think apps were something you kept releasing.
But now I feel that releasing is also "an opportunity for dialogue with my past self." When adding new features, I read old code. When fixing bugs, I reflect on decisions from back then. Each time, there's a discovery: "Oh, I was thinking that way back then."
Rather than knowing if I've improved, I can see how I've changed. That might be the most straightforward way to feel the accumulation.
Personal development is lonely. When no one uses it, it's really hard, and there are days when you release something and no one notices. There were countless nights when I thought, "Is there any point in continuing like this?"
But reading old code changed my feelings a little.
Because I didn't quit, that code still exists. The anxiety from back then, the hope, the affection for unused features—it's all there. It's not something anyone will evaluate, but it's definitely my footsteps.
I think going forward, things will probably go wrong more often than not. But the code I'm writing today might become a gift to the me two years from now.
Thinking that way, I felt like I could keep writing a little longer.
Lily（@bokuwalily）― Personal developer. Making iOS apps and web services in tandem with AI
🎁 For you who read to the end, there's a free bonus
LINEで「自動化」と送って受け取る（実装テンプレ7本）
Lily（@bokuwalily）― After leading a marketing organization of 50 people as CMO, I now make iOS apps and web services individually. I consult on customer acquisition, user flow design, and AI implementation and business automation
🖥️ Works and articles → bokuwalily.com
🐙 OSS → github.com/bokuwalily
🌍 Latest info and inquiries → X @bokuwalily
去年の秋、気まぐれで2年ほど放置していたアプリのコードを開きました。特に理由はありませんでした。「そろそろちょっと直してもいいかな」という、それだけの気持ちでした。 でも、最初のファイルを読み始めたとき、思わず画面から目を離してしまいました。そこにあったのは、コードだけではなかったからです。 あの頃の私が、そこにいました。判断の揺らぎも、焦りも、誰かに届いてほしいという淡い希望も、全部そのままの形で残っていました。日記には書かなかったことが、コードには書いてありました。今日はそういう話をさせてください。
日記は書こうと思わないと書けません。でも、コードは書かざるを得ない。機能を作ろうとすれば、何かを書くしかない。だから、そこには意図せず「あの日の判断」が刻まれます。
ファイルを読みながら最初に気づいたのは、変数名のつけ方がやたら防衛的だということでした。意味がわかりそうでわからない名前、括弧書きで「多分」「のはず」が混じったコメント。「ちゃんと動くか自信がなかったんだな」と、すぐにわかりました。自信があれば、もっとシンプルに書けるはずだからです。
今の私なら書かない、でも、あのとき書かずにはいられなかった。そういう痕跡が、ファイルを開くたびに出てきました。
アプリの構造を見ると、明らかに「とりあえず」で積み上げた跡がありました。
本来なら一箇所にまとめるべき処理が、あちこちに散らばっていました。「後で直す」つもりで書いたコードが、そのままリリースされて、2年経った今もそのまま動いています。
最初は恥ずかしかったです。でも、読み進めるうちに、恥ずかしさとは別の感情が出てきました。
あのとき、精一杯だったんだな、という気持ちです。
その散らばり方は、締め切り前の焦りそのものでした。「完璧にしてからリリース」ではなく、「何か動くものを出さなければ」という圧力。それがそのまま、コードの構造に写っていました。責めるよりも先に、なんだか懐かしくなってしまいました。
恥ずかしいものだけではありませんでした。
使われるかどうかわからないのに、丁寧に作ってある画面がありました。エラーメッセージが優しい言葉で書かれていて、「誰かがここで詰まったとき、ちゃんと助けたかったんだな」と伝わってきました。ほぼ誰も通らないであろうその画面に、あの頃の私は、ちゃんと気持ちを込めていました。
統計の画面には、使ってくれる人がいるかどうかも確認していないのに、細かい項目が丁寧に並んでいました。「こういう使い方をする人がいるかもしれない」という期待が、そのまま機能になっていました。
コードは製品であると同時に、「誰かの役に立てるかもしれない」という希望の保存場所でもありました。
個人開発を続けていると、だんだん気持ちが実用的になっていきます。「この機能は本当に必要か」「時間に見合うか」そういう問いばかり増えていく。それ自体は悪いことではないけれど、いつの間にか最初の楽しさが薄くなっていることがあります。
でも、あのコードの中には、そういう計算よりも前の気持ちがありました。「これ、あったら絶対便利だよな」「こういう操作感にしたら気持ちいいかも」という、純粋な好奇心の痕跡。
それを読んで、少し息が楽になりました。
正直に書くと、誰にも使われないまま削除した機能があります。
作るときはとても興奮していました。アイデアをノートに書き出して、画面のレイアウトまで手で描いて、実装に2週間かけました。リリースから3ヶ月間、その機能に触れたユーザーは、数字を確認する限り一人もいませんでした。
次のバージョンを作るとき、静かに削りました。
当時は「時間を無駄にした」と感じていました。でも、古いコードの中でその機能を見たとき、なんだか愛おしくなりました。使われなかったけれど、あの2週間があったから、次の機能の設計が少しだけ上手くなったのは確かです。失敗じゃなかったとは言いません。でも、無駄でもなかった。
個人開発の文脈では、「売れた/売れなかった」「見てもらえた/もらえなかった」という数字が目立ちます。Xに投稿すれば、反応の多さで可視化されてしまう。
でも、コードの中には数字に出ない記録があります。試行錯誤の痕跡、途中で方向を変えた跡、丁寧に書いたエラー処理、誰も通らない画面に込めた気持ち。それは誰も見ていないけれど、確かにそこにあります。
結果だけを見ていると、自分の歩みが消えていくように感じることがあります。でも、コードは覚えていてくれます。
古いコードを読んで、もう一つ気づいたことがあります。
あの頃の私は、未来の自分がこれを読むとは思っていなかった。だからこそ、素の状態で残っていました。でも今は、「2年後の自分が読んだとき、何を思うだろう」と意識するようになりました。
特別なことをしているわけではありません。コミットメッセージを、もう少しだけ丁寧に書くようにしました。「fix」「update」だけじゃなくて、「なぜそうしたか」を一行だけ添える。ドキュメントを増やすわけでも、コメントを詳しくするわけでもなく、ただ「この判断には理由がある」ということを残すだけです。
それだけで、未来の自分への手紙になります。
2年後に自分のコードを読んで、「ああ、あの頃こういうことを考えていたんだ」とわかるのは、単純に嬉しいことです。
日記は書くのが億劫でも、コードは否応なく書く。だったら、そこに少しだけ「気持ちの文脈」を混ぜておくのはそこまで難しくありません。技術的な正しさを追うよりも先に、「あの頃の自分が何を考えていたか」が伝わる書き方をする。それが今の私の、地味だけど大切な習慣になっています。
アプリは続けてリリースするものだと思っていました。
でも今は、リリースは「過去の自分との対話の機会」でもあると感じています。新しい機能を追加するときに古いコードを読む。バグを直すときに当時の判断を振り返る。そのたびに、「ああ、あのときはこう考えていたんだ」という発見があります。
うまくなっているかどうかよりも、変わってきたことがわかる。それが、積み重ねを実感する一番素直な方法かもしれません。
個人開発は孤独です。使ってもらえないときは本当につらいし、リリースしても誰にも気づかれない日もある。「このまま続ける意味があるのかな」と思う夜は、数え切れないくらいありました。
でも、古いコードを読んで、少し気持ちが変わりました。
やめなかったから、あのコードが今も残っています。あの頃の焦りも、希望も、使われなかった機能への愛着も、全部そこにある。それは誰かに評価されるものではないけれど、確かに私の歩みです。
これから先も、多分うまくいかないことの方が多いと思います。でも、今日書いているこのコードは、2年後の私への贈り物になるかもしれません。
そう思ったら、少しだけ、また書き続けようと思えました。
Lily（@bokuwalily）― 個人開発者。AIと二人三脚で、iOSアプリやWebサービスを作っています
🎁 最後まで読んでくれたあなたへ、無料の特典があります
LINEで「自動化」と送って受け取る（実装テンプレ7本）
Lily（@bokuwalily）― マーケ組織50名規模を統括するCMOを経て、いまは個人でiOSアプリやWebサービスを作っています。集客・導線設計と、AI導入・業務自動化の相談を受けています
🖥️ 制作物・記事 → bokuwalily.com
🐙 OSS → github.com/bokuwalily
🌍 最新情報・お問い合わせ → X @bokuwalily
