About

The instructor

Sriram G - statistical programmer and R developer, working across clinical reporting, data engineering and interactive application development.

The training here comes out of practical work: building ADaM datasets and TLFs, migrating teams from SAS to R, and maintaining Shiny applications that other people depend on. Every lesson exists because the material in it was needed on a real project.

NoteUpdate this page

Replace this section with your own biography, credentials, therapeutic-area experience and contact details. The structure below is a starting point.

Background

  • Statistical programming for clinical trials — SDTM, ADaM, TLF production
  • R package development and the pharmaverse ecosystem
  • Shiny application development and deployment
  • Python for data engineering and machine learning
  • SAS-to-R migration planning and delivery

Areas of focus

  • Reproducible, auditable analysis pipelines
  • Metadata-driven programming
  • Testing and validation of statistical software
  • Building capability in teams moving to open-source tooling

Why these courses exist

Most R training falls into one of two categories: a general-purpose data science course that never mentions a regulated environment, or a vendor course that teaches a specific tool without teaching the language underneath it.

Neither is much use to a statistical programmer who needs to produce a submission-grade dataset next month.

These courses are written for the middle ground:

  • Complete, runnable code. Not fragments. You can copy a lesson into RStudio and it does something.
  • Edge cases stated explicitly. Empty datasets, partial dates, boundary values, missing baselines. The cases that break in production are the ones covered.
  • Regulated work treated as normal. Reproducibility, traceability and validation are addressed in the lesson where they arise, not bolted on as a final chapter.
  • SAS comparisons where they help. And, more importantly, where the equivalence breaks down.
  • Honest about limitations. The Python course says plainly that there is no admiral for Python. The migration lesson says plainly when not to migrate.

How the material is structured

Every lesson follows the same shape:

  1. Learning objectives — what you will be able to do
  2. Explanation with runnable code — the concept, then the working example
  3. Callouts — warnings, common traps, and the details that matter
  4. Common mistakes table — what goes wrong and how to fix it
  5. Exercises with worked solutions — collapsed, so you can try first
  6. Recap — the points worth remembering

The exercises are the part that matters. The solutions are written out fully and explain the reasoning, not just the answer — including why a particular approach was chosen over the alternatives.

Corrections and contributions

Technical material goes stale. Package interfaces change, best practice moves, and errors survive review.

If you find a mistake, an outdated example, or an explanation that does not work, please say so — see Contact. Corrections are genuinely welcome and are the fastest way for this to improve.

Colophon

This site is built with Quarto, themed with a custom SCSS layer over Bootstrap 5, and published as static HTML. The source is plain Markdown, so every lesson is readable and diffable without rendering.

Code examples are shown but not executed at render time, which means the site builds anywhere without R, Python or any package installed. Output shown in comments is the output you should expect to see.

Back to top