devbox.id

Developer tools, self-hosted dev environments, productivity for solo engineers

Productivity Tools untuk Solo Developer yang Serius

by Marcus Chen
Productivity Tools untuk Solo Developer yang Serius

Kamu solo developer. Nggak ada tim, nggak ada yang review PR kamu jam 2 pagi, nggak ada yang nge-ping buat daily standup. Tapi deadline tetap ada, bug tetap datang, dan context switching antara nulis kode, deploy, dan balas email klien itu nyata banget sakitnya.

Masalah utama solo developer bukan kurang skill — tapi terlalu banyak hal yang harus dihandle sendirian. Gue pernah di titik di mana satu hari habis cuma buat ngurus infrastruktur, bukan nulis fitur. Itu momen gue mulai serius nyari productivity tools yang beneran bantu, bukan sekadar kelihatan keren di Twitter.

Artikel ini bukan daftar panjang tanpa konteks. Ini tools yang gue pakai sehari-hari sebagai solo developer, lengkap dengan kenapa dan bagaimana cara pakainya.

Masalah Nyata: Context Switching yang Makan Waktu

Solo developer itu harus jadi engineer, product manager, DevOps, dan kadang customer support sekaligus. Setiap kali kamu pindah konteks — dari nulis kode ke ngecek server log ke balas issue — ada biaya kognitif yang dibayar. Penelitian bilang butuh sekitar 23 menit buat balik fokus penuh setelah interrupt.

Jadi solusinya bukan kerja lebih keras. Solusinya: kurangi friction di setiap bagian workflow kamu.

1. Taskfile: Automasi Workflow Tanpa Ribet

Makefile itu powerful tapi syntaxnya kadang bikin pusing. Taskfile adalah alternatif modern yang pakai YAML dan jauh lebih readable.

Contoh kasus: kamu punya project yang butuh beberapa langkah buat development setup — jalanin database, migrate schema, terus start dev server. Tanpa automasi, kamu ketik ulang command yang sama puluhan kali sehari.

Buat file Taskfile.yml di root project:

version: '3'

vars:
  APP_PORT: 8080

tasks:
  dev:
    desc: Start full development environment
    deps: [db:start]
    cmds:
      - sleep 2  # tunggu DB ready
      - go run ./cmd/server -port {{.APP_PORT}}

  db:start:
    desc: Start PostgreSQL via Docker
    cmds:
      - docker compose up -d postgres
    status:
      - docker compose ps postgres | grep 'running'

  db:migrate:
    desc: Run database migrations
    cmds:
      - migrate -path ./migrations -database "postgres://localhost/myapp?sslmode=disable" up

  build:
    desc: Build production binary
    cmds:
      - go build -ldflags="-s -w" -o ./bin/server ./cmd/server

  deploy:
    desc: Build and push to server
    deps: [build]
    cmds:
      - rsync -avz ./bin/server user@myserver:/opt/myapp/
      - ssh user@myserver 'systemctl restart myapp'

Sekarang buat start dev environment kamu tinggal:

task dev

Dan buat deploy:

task deploy

Gotcha: Di task db:start, gue tambah status check supaya Docker container nggak di-restart kalau udah running. Tanpa ini, setiap task dev bakal restart database dan kamu kehilangan koneksi yang lagi aktif.

2. lazygit: Git Tanpa Ninggalin Terminal

GUI Git itu berat dan biasanya butuh kamu keluar dari flow. CLI Git murni itu powerful tapi verbose. lazygit adalah sweet spot — TUI (terminal UI) yang bisa kamu operasikan tanpa ninggalin terminal.

Install di macOS/Linux:

# macOS
brew install lazygit

# Ubuntu/Debian
LAZYGIT_VERSION=$(curl -s "https://api.github.com/repos/jesseduffield/lazygit/releases/latest" | grep -Po '"tag_name": "v\K[^"]*')
curl -Lo lazygit.tar.gz "https://github.com/jesseduffield/lazygit/releases/latest/download/lazygit_${LAZYGIT_VERSION}_Linux_x86_64.tar.gz"
tar xf lazygit.tar.gz lazygit
sudo install lazygit /usr/local/bin

Jalankan di dalam project directory:

lg

Yang paling gue suka: interactive rebase. Kamu bisa squash, reorder, atau edit commit message dengan navigasi keyboard tanpa hafal syntax git rebase -i HEAD~3.

Gotcha: Kalau kamu pakai Neovim sebagai editor dan lazygit, pastiin environment variable GIT_EDITOR di-set dengan benar. Kalau nggak, lazygit bakal buka editor yang salah waktu kamu edit commit message.

# Tambahkan ke .bashrc atau .zshrc
export GIT_EDITOR=nvim

3. Hurl: Test HTTP Endpoint Tanpa Postman

Postman itu berat, butuh akun, dan file collection-nya susah di-version control dengan bersih. curl itu powerful tapi verbose buat testing workflow yang kompleks. Hurl adalah tool CLI yang bikin kamu bisa nulis HTTP tests dalam format teks yang bisa di-commit ke repo.

Install:

# macOS
brew install hurl

# Linux
curl -LO https://github.com/Orange-OpenSource/hurl/releases/latest/download/hurl-x.y.z-x86_64-unknown-linux-gnu.tar.gz
# Extract dan pindah ke /usr/local/bin

Buat file tests/api.hurl:

# Test: Register user
POST http://localhost:8080/api/auth/register
Content-Type: application/json
{
  "email": "test@example.com",
  "password": "secret123"
}

HTTP 201
[Captures]
user_id: jsonpath "$.data.id"

# Test: Login dengan credentials yang sama
POST http://localhost:8080/api/auth/login
Content-Type: application/json
{
  "email": "test@example.com",
  "password": "secret123"
}

HTTP 200
[Captures]
token: jsonpath "$.data.token"
[Asserts]
jsonpath "$.data.token" isString

# Test: Get profile dengan token
GET http://localhost:8080/api/users/{{user_id}}
Authorization: Bearer {{token}}

HTTP 200
[Asserts]
jsonpath "$.data.email" == "test@example.com"

Jalankan:

hurl --test tests/api.hurl

Output-nya clean, dan kalau ada yang fail kamu langsung tahu di bagian mana. File .hurl ini bisa di-commit ke repo, jadi dokumentasi sekaligus integration test.

Gotcha: Hurl by default nggak follow redirect. Kalau API kamu return 301/302, tambahkan flag --location.

4. Zellij: Terminal Multiplexer yang Nggak Butuh Hafalan Keybinding

tmux itu standar industri, tapi keybinding-nya nggak intuitif buat yang baru mulai. Zellij hadir dengan UI yang menampilkan keybinding aktif di layar — jadi kamu nggak perlu hafal.

Install:

# macOS
brew install zellij

# Linux
bash <(curl -L zellij.dev/launch)

Setup layout untuk development workflow:

// ~/.config/zellij/layouts/dev.kdl
layout {
    pane split_direction="vertical" {
        pane size="60%" {
            // Editor pane
        }
        pane split_direction="horizontal" size="40%" {
            pane {
                // Dev server
                command "task"
                args "dev"
            }
            pane {
                // Logs / testing
            }
        }
    }
    pane size=1 borderless=true {
        plugin location="zellij:status-bar"
    }
}

Jalankan dengan layout ini:

zellij --layout ~/.config/zellij/layouts/dev.kdl

Sekarang setiap kali kamu mulai kerja, satu command langsung setup workspace dengan editor, dev server, dan terminal kosong buat testing.

Gotcha: Zellij dan tmux bisa conflict kalau kamu nested (tmux di dalam Zellij atau sebaliknya). Pilih salah satu dan stick to it.

5. Obsidian dengan Local Vault: Second Brain untuk Kode

Sebagai solo developer, dokumentasi itu sering diabaikan karena "nanti aja". Tapi 3 bulan kemudian kamu buka project lama dan nggak ingat kenapa kamu bikin keputusan arsitektur tertentu.

Obsidian dengan local vault (bukan cloud sync berbayar) adalah solusi yang gue pakai. Semua notes tersimpan sebagai plain Markdown di local machine, bisa di-sync via Git.

Struktur folder yang gue pakai:

~/notes/
├── projects/
│   ├── myapp/
│   │   ├── architecture.md
│   │   ├── decisions/
│   │   │   ├── 2024-01-why-postgres.md
│   │   │   └── 2024-03-switch-to-redis.md
│   │   └── runbooks/
│   │       ├── deploy.md
│   │       └── rollback.md
├── til/  # Today I Learned
│   ├── 2024-golang-context-cancel.md
│   └── 2024-postgres-explain-analyze.md
└── inbox.md  # Dump semua ide dulu di sini

Sync via Git:

# Di dalam ~/notes/
git init
git remote add origin git@github.com:username/notes-private.git

# Buat script sync sederhana
cat > ~/bin/notes-sync << 'EOF'
#!/bin/bash
cd ~/notes
git add -A
git commit -m "sync: $(date '+%Y-%m-%d %H:%M')"
git push origin main
EOF
chmod +x ~/bin/notes-sync

Tambahkan ke crontab buat auto-sync tiap jam:

crontab -e
# Tambahkan:
0 * * * * /home/username/bin/notes-sync >> /tmp/notes-sync.log 2>&1

Gotcha: Kalau kamu pakai Obsidian di multiple device, conflict bisa terjadi kalau dua device edit file yang sama sebelum sync. Solusinya: selalu pull dulu sebelum mulai nulis, atau pakai branch per device.

6. Watchexec: Auto-Reload Tanpa Framework-Specific Tool

Banyak framework punya built-in file watcher, tapi kalau kamu kerja di luar ekosistem itu — atau mau trigger command arbitrary waktu file berubah — watchexec lebih fleksibel.

# Install
cargo install watchexec-cli
# atau
brew install watchexec

Contoh penggunaan:

# Rerun tests setiap kali file Go berubah
watchexec -e go -- go test ./...

# Rebuild dan restart server
watchexec -e go -r -- go run ./cmd/server

# Generate docs setiap kali file Markdown berubah
watchexec -e md -- ./scripts/build-docs.sh

Kombinasi dengan Taskfile:

tasks:
  watch:test:
    desc: Run tests on file change
    cmds:
      - watchexec -e go -- go test ./... -v

Gotcha: Flag -r (restart) di watchexec akan kill process sebelumnya sebelum jalanin yang baru. Ini bagus buat server, tapi hati-hati kalau process kamu butuh graceful shutdown — tambahkan --stop-signal SIGTERM dan pastiin app kamu handle SIGTERM dengan benar.

Yang Gue Lakuin Sekarang

Setup ini bukan sesuatu yang gue bangun dalam semalam. Mulai dari satu tool, biasakan, baru tambah yang berikutnya.

Kalau kamu baru mulai, urutan yang gue rekomendasikan:

  1. Taskfile dulu — automasi command yang paling sering kamu ketik. ROI-nya paling cepat kerasa.
  2. lazygit — kalau kamu masih ketik git add -p dan git log --oneline manual tiap hari.
  3. Hurl — kalau kamu bangun API dan masih buka Postman buat test.
  4. Zellij — kalau kamu sering buka banyak terminal window dan mulai bingung sendiri.
  5. Obsidian — kalau kamu udah pernah buka project lama dan nggak ngerti kode yang kamu tulis sendiri.
  6. Watchexec — kalau ada workflow yang masih kamu trigger manual padahal bisa di-automate.

Productivity tools terbaik untuk solo developer adalah yang ngurangin friction, bukan yang nambah hal baru untuk dipelajari. Semua tools di atas punya learning curve yang flat dan langsung kelihatan manfaatnya di hari pertama.

Coba satu dulu. Kalau stuck, buka issue di repo-nya — komunitas open source tools ini aktif banget.