Beginner programmer.
I value shipping working systems over theoretical perfection.
If it runs, is debuggable, and can be delivered on time, it is good enough to start.
- Implementation support for research ideas
- Prototypes that actually run (not just slides or pseudo-code)
- Data pipelines, experiments, evaluation scripts
- Turning papers and assignments into runnable code
- Programming and AI/ML coursework support
- Focused on understanding and completing assignments, not just explanations
- Make it run → make it correct → make it maintainable
- 300+ project executions
- Small-to-medium deliverables
- Deadline-driven fixes, migrations, prototypes, and rewrites
- Freelance outsourcing
- Short-term consulting + direct implementation
- Research-related deliveries
- 3 deliveries to Korean government research institutions
- Academic assistance
- Programming / AI·ML coursework and research prototype support
- Reproducible code, clean reports, runnable environments
Anonymized samples and before/after diffs can be shared when appropriate.
- Prefer explicit results over hidden behavior
- Early exits (guard clauses) over deep nesting
- Small functions, simple control flow
- Policies over ad-hoc decisions
- Deterministic behavior whenever possible
- Security and resource safety as defaults
Languages
- Python, TypeScript/JavaScript, C#, Java, R
Common work
- HTTP APIs
- Async / concurrency
- Data processing & evaluation scripts
- Automation and tooling
Environments
- Windows / Linux
- Containers when needed
- Making research code actually runnable
- Turning messy scripts into something debuggable
- Simple systems that survive real usage
- Automation that removes manual work
- Delivery-first mindset
- Minimal runnable version first
- Instrumentation and edge-case handling next
- Clear notes on what works, what doesn’t, and why
Physics Education → Manual Labor → Developer
I started in physics education, then spent time in manual labor before transitioning into programming.
This path shaped a pragmatic mindset: problems are meant to be solved, not theorized endlessly.
Deadlines are real.
Working systems matter more than elegant abstractions that never ship.
I spent 2 years under an SI broker, learning how the industry actually moves:
client expectations, scope creep, and delivery pressure.
After that, I went independent as a solo contractor (개인사업자), handling projects end-to-end without middlemen.
I do not write papers, and I do not claim to be an academic researcher.
But if you give me a paper with equations, I can turn those equations into running code.
- Loss functions
- Evaluation metrics
- Model architectures
If it is written in math, I can make it execute.
This has been the core of my research-adjacent work:
helping graduate students and labs turn methods that exist on paper into systems that actually run.
I have worked across multiple paradigms and take what is useful from each:
- OOP — when domain modeling and encapsulation make sense
- FP — for predictable data transformations and avoiding hidden state
- DOD (Data-Oriented Design) — when performance and cache efficiency matter (e.g., Unity ECS)
- Effect-Oriented Programming — currently exploring ways to make side effects explicit and composable
No single paradigm is correct.
The job dictates the tool.
- GitHub Issues / Discussions for technical topics
- For work inquiries: open an issue with scope, deadline, and constraints