DEV Community: Rizky Haksono

Why Men Don't Need to Hold It In

Rizky Haksono — Fri, 04 Apr 2025 08:26:49 +0000

“Men don't cry” sounds like a small sentence. It is not. Repeated often enough, it teaches boys to translate sadness into silence and fear into anger—two emotions that are considered more acceptable than vulnerability.

I do not think the problem is that men cannot cry. The problem is that many men learn there may be a social cost when they do.

Emotion is not the opposite of strength

Crying is one way the body responds to pain, grief, exhaustion, relief, or being overwhelmed. It does not tell us whether someone is capable, dependable, or resilient.

Strength is not the absence of feeling. Sometimes it is the ability to name what is happening before it leaks out as withdrawal, irritability, or self-destruction.

Why silence becomes a habit

A person may stay quiet because previous honesty was mocked, minimized, used against them, or met with an immediate attempt to “fix” them. After enough experiences like that, silence can feel safer.

This is why simply telling someone to open up is not enough. Trust is built by what happens after they speak.

How to make the conversation safer

When a friend shares something difficult, I try to remember a few simple things:

listen before offering advice;
do not turn vulnerability into a joke later;
ask whether they want ideas or only someone to hear them;
keep private things private;
check in again after the moment has passed.

None of this requires perfect words. Presence is often more useful than a speech.

Crying is not the only measure

Not everyone processes emotion by crying, and nobody should be pressured to perform vulnerability. The goal is not to make every man cry. It is to make room for honest emotion without punishment.

That might look like talking, writing, prayer, exercise, therapy, sitting quietly with someone, or finally admitting, “I am not doing well.”

When support needs to be professional

Friends matter, but they cannot replace professional care. Persistent hopelessness, thoughts of self-harm, panic, or an inability to function deserve help from a qualified mental-health professional or local crisis service.

Asking for that help is not failure. It is a practical response to pain.

A better sentence

Instead of teaching men not to cry, we can teach them that emotions are information, vulnerability requires courage, and seeking support is part of taking responsibility for their lives.

There is nothing weak about being human in public.

A Time Management System I Can Actually Stick To

Rizky Haksono — Mon, 02 Dec 2024 17:22:26 +0000

I have tried complicated productivity systems before. Most of them lasted a week. The problem was not the app or the method; it was that maintaining the system became another task.

What works better for me is deliberately boring: one list, a small number of priorities, and protected blocks of time.

Start with capacity, not ambition

At the beginning of the day I choose three outcomes at most:

one task that moves the main project forward;
one maintenance task;
one small task I can finish when my energy is lower.

Everything else stays in the backlog. A long list may look productive, but it makes every item feel equally urgent.

Put work on the calendar

A task list tells me what matters. A calendar forces me to decide when it can happen.

I normally reserve a focused block for engineering work, then leave smaller windows for messages, reviews, and administration. I also leave empty space. A schedule with no margin breaks as soon as a meeting runs late or a bug takes longer than expected.

Make the next action obvious

“Work on portfolio” is not a useful task. “Fix the mobile education layout and test it at 390px” is.

When I stop working, I leave a short note describing the next action. That tiny habit reduces the time I spend reconstructing context the following day.

Use a shutdown ritual

At the end of the day I spend a few minutes on three questions:

What did I actually finish?
What is blocked, and by whom or what?
What should be the first action tomorrow?

Then I close the work session. Rest is not a reward for clearing an infinite list; it is part of being able to do good work again.

What I stopped doing

I no longer track every minute, maintain several overlapping to-do apps, or treat a missed plan as a personal failure. Estimates are guesses. The useful response is to adjust the plan, not to build a prettier spreadsheet around the miss.

The system in one sentence

Choose less, schedule the important work, define the next physical action, and review what really happened.

It is not a revolutionary system. That is exactly why I can keep using it.

Elysia.js on Bun: A Practical First Look

Rizky Haksono — Mon, 02 Dec 2024 17:19:42 +0000

I first tried Elysia because I wanted to know whether Bun could make a small TypeScript API feel simpler, not because I needed another framework to collect.

The short answer: the setup is genuinely quick, and the type inference is the interesting part. The longer answer is that a fast hello-world is not enough reason to move an existing backend.

Start with the smallest useful API

Create the project:

bun create elysia app
cd app
bun dev

A small route looks like this:

import { Elysia, t } from "elysia"

const app = new Elysia()
  .get("/health", () => ({ ok: true }))
  .post(
    "/notes",
    ({ body }) => ({ id: crypto.randomUUID(), ...body }),
    {
      body: t.Object({
        title: t.String({ minLength: 1 }),
        body: t.Optional(t.String()),
      }),
    },
  )
  .listen(3000)

console.log(`Listening on http://localhost:${app.server?.port}`)

What I like here is that validation sits beside the route. The schema is useful at runtime, while TypeScript infers the body type for the handler. There is less distance between what the endpoint accepts and what the editor understands.

What felt good

The initial project is small enough to read in one sitting.
Route definitions are concise without hiding the HTTP model.
Runtime validation and TypeScript inference work together.
Bun starts the development server quickly.

That combination makes Elysia pleasant for prototypes, internal services, and focused APIs.

What I would check before using it at work

A framework choice is more than request throughput. I would also check:

whether the libraries we need behave correctly on Bun;
how the team will handle logging, tracing, migrations, and background jobs;
whether deployment supports the runtime without special workarounds;
how easy it will be for another engineer to maintain the service six months later.

If an existing Express or Fastify service is stable, a benchmark alone would not persuade me to rewrite it. Migration risk is real, and mature ecosystems are valuable.

My current take

Elysia is worth trying when Bun is already an acceptable runtime and end-to-end typing matters to the project. I would reach for it on a small new service before considering it for a large migration.

The framework made a strong first impression because it removes ceremony. The next test is not another hello-world; it is building one complete service with a database, authentication, tests, observability, and deployment. That is where a backend framework earns its place.

Docker, Explained Through the Problem It Solves

Rizky Haksono — Mon, 02 Dec 2024 17:17:23 +0000

The first useful thing Docker gave me was not “cloud-native architecture.” It was a boring promise: the application should behave the same way on another machine.

Before containers, a setup could depend on the exact Node version, system packages, environment variables, or a database installed on one laptop. Docker makes those assumptions explicit and packages the application process with its runtime dependencies.

Image, container, and volume

These three words explain most day-to-day Docker work:

An image is an immutable template built from a Dockerfile.
A container is a running instance of that image.
A volume stores data that should survive when a container is replaced.

A container is not a tiny virtual machine. Containers share the host kernel, which is one reason they usually start faster and use fewer resources than full VMs.

A small Node example

FROM node:22-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=deps /app/node_modules ./node_modules
COPY . .
USER node
CMD ["npm", "start"]

Build and run it:

docker build -t notes-api .
docker run --rm -p 3000:3000 --env-file .env notes-api

The port mapping exposes container port 3000 on the host. The environment file supplies configuration at runtime instead of baking secrets into the image.

Where Docker helps

Docker is useful when I need:

reproducible local environments;
isolated services such as Postgres or Redis;
the same artifact in CI and deployment;
an explicit record of system dependencies.

It does not automatically make an application scalable or secure. A large image is still large. A process running as root is still risky. A stateful service still needs backups.

A few habits that prevent pain

Use a .dockerignore file, pin important base-image versions, run as a non-root user, keep secrets outside the image, and rebuild images instead of manually changing running containers.

For local multi-service work, Compose is often enough:

services:
  app:
    build: .
    ports: ["3000:3000"]
    env_file: .env
  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_PASSWORD: local-only

The mental model I keep

Docker packages a process and its dependencies behind a repeatable boundary. That boundary is valuable, but it is not magic. You still need to understand networking, storage, configuration, and the application itself.

Choosing SSR, ISR, or CSR in Modern Next.js

Rizky Haksono — Mon, 02 Dec 2024 17:16:31 +0000

The SSR/ISR/CSR comparison is useful, but the usual explanation often turns it into three competing page types. In modern Next.js, they are better understood as decisions about where data is fetched, when work happens, and what can be cached.

I use this question first: who needs the data, and how fresh must it be?

Server rendering for request-time data

Render on the server when the response depends on the current request: authentication, cookies, headers, or data that must be fresh.

export default async function AccountPage() {
  const account = await fetch("https://api.example.com/account", {
    cache: "no-store",
  }).then((response) => response.json())

  return <h1>Welcome, {account.name}</h1>
}

The browser receives useful HTML, but the server performs the work for each request. Use that freshness deliberately; do not disable caching everywhere by habit.

Cached server rendering and revalidation

For documentation, product pages, or articles, the same result can often be shared between visitors and refreshed periodically.

export default async function ProductPage() {
  const products = await fetch("https://api.example.com/products", {
    next: { revalidate: 3600 },
  }).then((response) => response.json())

  return <ProductList products={products} />
}

This is the modern equivalent of the problem ISR solves: serve cached output quickly, then revalidate it according to the application's freshness requirements. For content-driven updates, tag-based or on-demand revalidation can be clearer than an arbitrary timer.

Client-side fetching

Fetch in the browser when the data belongs to an interaction after the page loads: autocomplete results, a live chart, or a user-triggered refresh.

"use client"

import useSWR from "swr"

const fetcher = (url: string) => fetch(url).then((response) => response.json())

export function LiveStatus() {
  const { data, isLoading } = useSWR("/api/status", fetcher, {
    refreshInterval: 10_000,
  })

  if (isLoading) return <p>Checking status…</p>
  return <p>{data.message}</p>
}

CSR is not automatically faster. It can mean sending an empty shell, downloading JavaScript, and making another request before the user sees the content.

The practical decision

Need	Start with
Request-specific or uncached data	Server rendering
Shared content that changes occasionally	Cached server rendering + revalidation
Interaction-owned or continuously updating data	Client fetching

A single page can use all three. The product description may be cached, account pricing may render per request, and a stock indicator may update in the browser.

What I default to

I keep data and rendering on the server unless an interaction genuinely needs client state. Then I add the smallest client component around that interaction. This usually ships less JavaScript and makes the loading path easier to reason about.

The useful question is not “Which acronym wins?” It is “What is the cheapest place to do this work while meeting the freshness and interaction requirements?”

SDLC in Practice: The Loop Behind Shipping Software

Rizky Haksono — Tue, 03 Sep 2024 04:15:25 +0000

I used to see the Software Development Life Cycle as a diagram for reports: requirements, design, implementation, testing, deployment, maintenance. Real projects rarely move through those boxes once in a perfect circle.

The useful part of SDLC is not memorizing the phases. It is making sure the team answers the right questions before and after code is written.

1. Understand the problem

Before discussing frameworks, clarify the user, the painful workflow, the expected outcome, and the constraints. “Build a dashboard” is a request. “Help an operator find failed jobs within two minutes” is a problem we can test.

Useful output at this stage can be small: a short problem statement, acceptance criteria, open questions, and a list of risks.

2. Choose the smallest workable design

Design includes more than UI. It covers data ownership, boundaries between services, failure behavior, security, and how the system will be observed.

I prefer decisions that are easy to reverse. A short design note explaining why is often more valuable than a complicated diagram with no trade-offs.

3. Build in reviewable slices

Large changes hide risk. A vertical slice—a thin path from interface to data and back—gives the team something real to review early.

A useful pull request should make its intent visible, keep unrelated cleanup separate, and include enough verification that another engineer can trust the change.

4. Test the behavior that matters

Testing is not a phase saved for the end. The test strategy should follow the risk:

unit tests for important rules;
integration tests at system boundaries;
end-to-end tests for critical user paths;
manual checks for layout, accessibility, and unexpected interactions.

A green test suite does not prove the product solves the original problem. Acceptance criteria still matter.

5. Release with a way back

Deployment should answer three questions: how do we know it worked, how do we detect harm, and how do we reverse it?

That may mean logs and metrics, a feature flag, a staged rollout, database migration safeguards, or a tested rollback command. The level of ceremony should match the cost of failure.

6. Learn from production

Production feedback starts the next loop. Support questions, latency, errors, and user behavior reveal assumptions that planning could not.

Maintenance is not the sad ending of development. It is where software spends most of its life.

Waterfall or Agile?

Waterfall can fit work with stable requirements and costly phase changes. Iterative methods fit uncertainty better because they shorten the distance between an assumption and feedback. Most teams use a mixture, whether or not their process document admits it.

My practical version of SDLC

Define the outcome, expose the riskiest assumption early, ship a reviewable slice, verify it, observe it, and feed what you learn into the next decision.

The lifecycle is valuable when it helps people think clearly. When it becomes paperwork detached from the product, the diagram has replaced the work.

MBKM Batch 6: What I Learned Building Software at BIGIO

Rizky Haksono — Mon, 02 Sep 2024 10:25:18 +0000

MBKM Batch 6 gave me something coursework could not: six months of working inside a software team where incomplete requirements, unfamiliar code, and deadlines were normal parts of the job.

In 2024 I joined PT Bejana Investidata Globalindo (BIGIO) as a full-stack developer intern. I arrived expecting to improve my coding. I left with a much better understanding of how engineers learn inside a real project.

The first month: real-time communication

My first assignment was to build an application using WebSocket communication with PostgreSQL for persistence. The technology was new enough to be uncomfortable, which made the task useful.

The difficult part was not opening a socket. It was thinking about connection state, how data should be stored, and what the application should do when the happy path failed. That project taught me to look beyond a demo that merely works on my machine.

Debugging a .NET project for the first time

I later worked on an existing .NET codebase for Bio Farma's eCRF project. My task involved a bug related to patient status.

I had not worked professionally with .NET before. Instead of trying to understand the entire system at once, I traced the affected flow, reproduced the issue, read the surrounding code, and narrowed the change. That process became more valuable than memorizing framework syntax.

React, Spring Boot, and a three-day feature

In April I implemented a data-export feature in a React and Spring Boot application. Spring Boot felt verbose compared with the tools I knew, but the explicit structure also made responsibilities easier to locate once I understood the project.

I completed the feature in three days. The useful lesson was not the speed itself; it was learning how to enter an unfamiliar stack, find the relevant path, and deliver a bounded change without pretending to know everything first.

The habits around the code

Every Thursday the team held knowledge-sharing sessions. I also practiced LeetCode problems to improve how I broke down logic.

In May, work on the Info Pangan Jakarta admin and user applications gave me a clearer view of code organization: folder boundaries, naming, and readable structure matter because code is read by a team, not only executed by a computer.

Life outside the office

The internship was also six months of living and learning with other people. On weekends, friends and I explored Yogyakarta—cafés, street food, Malioboro, the hills to the south, and occasional trips outside the city.

Those breaks were not separate from doing good work. They helped us reset, talk about things other than tickets, and return with more energy.

On June 21, 2024, we celebrated BIGIO's anniversary together. It was a simple gathering with nasi kuning, but it remains one of the moments that makes the internship feel personal rather than just another line on a résumé.

What stayed with me

The internship improved my technical range—WebSocket, PostgreSQL, .NET, React, and Spring Boot—but the more durable lesson was how to work when the stack is unfamiliar.

Reproduce the problem. Read before changing. Ask focused questions. Keep the scope clear. Share what you learn. Leave the code easier for the next person to understand.

That is what I carried forward from MBKM Batch 6 and my time at BIGIO.