Hello, and welcome to my profile. My name is Eduardo - grab a cup of coffee and allow me to introduce myself.

I build data platforms and production-grade data systems where messy real-world inputs are transformed into reliable, auditable, and analysis-ready products.

In practical terms, my work lives somewhere between:

• Data ingestion - where reality arrives poorly formatted and with opinions.
• Transformation layers - where Python, SQL, Spark, and modeling discipline try to restore civilization.
• Data quality - because a pipeline that runs and a pipeline that is correct are not the same animal.
• Delivery - where analytics, BI, ML, and internal users need datasets that are stable enough to trust and boring enough to maintain.

I specialize in Python, SQL, PySpark/Spark, cloud and hybrid data infrastructure, ETL/ELT pipelines, data modeling, validation frameworks, and reproducible platform workflows. I have worked across environments involving AWS, GCP, Azure, HPC clusters, Docker/Kubernetes, CI/CD, and large heterogeneous datasets that rarely introduce themselves politely.

My engineering bias is simple: build systems that are clear, testable, observable, and maintainable after the original excitement has left the room.

This usually translates to:

• Production data pipelines with strong reproducibility, monitoring, and failure handling
• Scalable batch and distributed processing for high-volume analytical workloads
• Data modeling layers supporting analytics, BI, reporting, and ML workflows
• Validation and governance practices for environments where correctness is not decorative
• Cloud, hybrid, and HPC workflows designed to survive both scale and human memory

My background includes complex healthcare and enterprise data environments, but my current professional identity is straightforward: Senior Data Engineer / Data Platform Engineer. Machine Learning is still part of the toolbox, but the main job is now the plumbing, contracts, orchestration, and reliability that make downstream intelligence possible.

I value clean design, explicit trade-offs, and systems that are understandable by humans - not just machines with suspicious confidence.

Ethics, reproducibility, and long-term sustainability are not optional; they are part of the job.

Availability | Currently open to remote, hybrid, relocation-friendly, and long-term Data Engineering / Data Platform roles. See contact details. Relocation and onboarding take planning - good systems (and good moves) benefit from doing things properly.

Cheers.

    LinkedIn: https://www.linkedin.com/in/eduardogade/

    Website & Blog: https://www.gusmaolab.org

    CV/Resume: https://www.gusmaolab.org/cv/CV_Eduardo_Gusmao.pdf

    Stack Overflow: https://stackoverflow.com/users/32223943/eduardo-gusmao

    Medium: https://medium.com/@eduardogade

    Preferred contact: Email | LinkedIn

    Response time: 1-2 business days

    Open to remote, hybrid, or relocation

    See [availability & engagement details](#availability)

    See [writing & communication details](#communication)

    See [education](#education) & [leadership details](#career)

Open-source involvement is treated as an extension of day-to-day engineering practice rather than a separate résumé line - it is where tooling, methods, and lessons from production work get generalized and given back.

The most concrete example is the Apache Spark committer status awarded by the Apache Software Foundation in 2025, which followed sustained engagement with the project's distributed-processing internals through professional and personal work. Beyond that, most of the ongoing contribution activity currently lives in the personal toolkit showcased under Pinned Repositories - actively maintained libraries for statistics, regulatory genomics, chromatin analysis, and small-scale automation - and in the volunteering commitments described under Causes.

A broader, evidence-backed view of pull requests, issue triage, and cross-project reviews across external organizations is still being organized for public presentation. Rather than publish an incomplete or padded picture, this subsection will be expanded once that material is ready to stand on its own.

Additional breakdowns of repositories, commit language distribution, and contribution timing - not already shown above.

The dashboard above already covers language mix, commit activity, and contribution cadence well. What is intentionally not here yet is a second layer of analytics: how these tools get used and reviewed outside of direct authorship - dependency graphs, downstream adoption, and external review activity.

No currently available public tooling produces that view at a quality bar consistent with the rest of this page without either being self-hosted or relying on metrics (like early-stage star counts) that would be more decorative than informative for research tooling with a narrow, specialist audience. Rather than fill the space with a vanity widget, this section stays intentionally reserved until metrics that are actually meaningful - closer to genuine downstream engineering usage than surface-level GitHub counters - become available.

Complete technology inventory, synchronized with CV.yaml and grouped by domain. Icons shown where a stable public icon set provides one; unmarked names are listed as text only.

Programming Languages

Data Engineering & Orchestration

Databases & Storage

Cloud & Infrastructure

Machine Learning & AI

Scientific & Bioinformatics Computing

Web, APIs & Dashboards

Observability & DevOps

Documentation & Markup

The Lancet · Oct 18, 2025

Contributions:

• Responsible for orchestrating the LATAM-branch with 45+ PIs and 200+ researchers.
• Horizontal meetings for data and experience sharing have shown great success, with ~380% more efficiency than the second most efficient branch - per capita.
• Has solved pharmacological conflict of interests by cross-deployment and blind-genotype blind-phenotype strategy, which exhibit 17% increased accuracy over North America (first COI - percapita) and 5% over Asia (second COI - per capita).

Cell Reports · Nov 26, 2024

Contributions:

• The tool Bloom has increased analysis mechanism by promoting different views into the regulatory spatial configuration, resulting in ~50% wet-lab equipment cost reduction and solving a stalled-case.
• Provided personal guidance towards architecture and Hi-C methodology, saving 15% overall lab-time.
• Overall, this was the first non-trivial non-intermediary-distance (>1Gbp) lncRNA interference in a region unknown to be a regulatory enhancer.

The Lancet · Jul 15, 2023

Contributions:

• Responsible for orchestrating a team of 3 brazilian PIs and 5 independent investigators.
• Used scrum, coupled with CRISP-DM, delivering net gains (profitability converted back) through network revenue saving and wet/dry-lab material cost reduction.
• Developed national-scale geno/phenotype QC pipeline - Fabric (Phenoteka Module) - used across 20+ institutes.

The New England Journal of Medicine · Oct 11, 2022

Contributions:

• Developed Blacksmith, that coupled with Bloom improved operating margin by over 15%.
• Freed at least 15 engineering hours per week with Blacksmith coupled with Apollo.
• Intending to lower carbon footprint, we adopted a trademarked DB 'bit-brushing' methodology (currently owned by Databricks Inc.).

Molecular Systems Biology · Jun 24, 2021

Contributions:

• Analized Spatial Chromatin Biology and RNA-seq to identify - for the first time - HMGB1 as a 'rheostat' factor.
• Reduced cloud compute costs by 40% using Apollo's strong mathematical features and Bloom to analyse Chromatin conformation.
• After this project's results, we have earned an ESG compliance through impeccable waste management and safety handling.

Genome Research · Apr 6, 2020

Contributions:

• Analized most omics in a single project: ChIP-seq, degron-X, RNA-seq, Hi-C, STORM, DNase-seq, ATAC-seq, MSMS and MS-based microscopy.
• Developed Musique, shortening development cycles by ~9 weeks.
• Musique saved 300 GPU-hours per month by performing simple heuristics which are generalizeable to any dataset.

Molecular Cell · Jul 25, 2019

Contributions:

• Patented technique for BLISS-seq data processing, earning ~25% extra funds for the laboratory.
• Lower wet-lab costs using dry-lab tools by ~30% (estimated for this project); achieving reproducible and insightful results on MLL fusions.
• Created the triple-correlation method. Translating category theory into a real-world phenomenon.

Molecular Cell · May 17, 2018

Contributions:

• Developed Bloom and Apollo, which reduced processing time by at least 3 months.
• Very agile methodology with microprocessed multicycled days, leading to novel discoveries and decreasing overall time-to-delivery.
• Reduced local infrastructure storage footprint by ~100TB with Bloom & Apollo.

Nature · Jan 23, 2017

Contributions:

• Devised bioinformatics pipelines with collaborators and created the Gaussian-as-DPMM method of clustering, increasing speed by, at least, ~100x.
• Clustering was able to identify 3+ unique subtypes never previously reported.
• Created a deep regulatory network, especially with SHKBP1 ERBB3 and TGFBR2; which contained 98% of the cancer mortality information variability.

Nature Methods · Feb 22, 2016

Contributions:

• Landmark study on comparing 12+ footprinting methods. The study was the cover of Nature Methods magazine.
• Without any dry experiment, we were able to identify the limits of sequencing technologies, and propose results that exceded ~5% AUPR of known methods.
• Our method - Olympus (published in 2023) - offers ~7x most complete analysis of regulatory genomics than any other tool.

Nucleic Acids Research · Oct 17, 2015

Contributions:

• First use of Faun, the motif enrichment analysis that uses hypergeometric distributions to query the sensitivity and specificity of TF occupancy in a certain genomic region.
• Proposed the usage of Cytoscape, widely minimising meeting preparation time by ~25%.
• Proposed use of fewer histone modification essays by recreating chromatin states in silico; thus, minimizing project costs by ~30%

I treat writing as an engineering discipline, not an afterthought bolted onto the end of a project. A pipeline that nobody can explain six months later is not really finished, no matter how well it runs today - the explanation is part of the deliverable, and it degrades just like code does if nobody maintains it.

Most of what I write falls into two categories: documentation that has to survive contact with someone else's Monday morning, and architecture notes that have to survive contact with my own memory a year from now. Both audiences are unforgiving in the same way - they punish vagueness, reward precision, and do not care how elegant the underlying system is if the explanation doesn't hold up. Writing clearly about a system is often the fastest way to discover that it isn't as clearly designed as I thought.

The Atlas Learning Series and the posts on Gusmao Lab and Medium exist for the same reason internal design docs exist: complexity that stays in one person's head is a liability, and complexity that gets written down - honestly, without inflating it - becomes something a team can actually build on.

Geography is a genuine preference, not a hard boundary. Europe and Brazil are where my professional and personal ties are strongest, so a role based there - or a remote/hybrid arrangement rooted there - tends to be the smoothest fit. That said, a worldwide, well-run, technically serious opportunity is always worth a conversation; relocation and onboarding just take a bit more planning, the same way any well-run migration does.

What I optimize for in a team is closer to craftsmanship than throughput. I would rather ship a system that is a little slower to build and considerably easier to operate, extend, and hand off, than one that is fast to demo and expensive to live with. That preference shows up as a bias toward explicit trade-offs, readable code, tests that actually catch regressions, and documentation that survives the person who wrote it moving on to something else.

Productivity, in my experience, tracks environment more than effort. Teams with reproducible builds, sane CI/CD, infrastructure-as-code, and automation around the boring parts of the job consistently ship better software than teams without them - independent of talent, tooling brand, or operating system. I look for that kind of environment because it is where careful engineering actually compounds instead of getting rebuilt from scratch every eighteen months, and I try to leave every team I join a little closer to it than I found it.

Collaboration matters just as much as any individual technical choice. The best systems I have worked on came out of teams that argued about trade-offs early, wrote decisions down, and treated architecture as something owned collectively rather than defended individually - that is the kind of team I look for, and the kind I try to build.

The expanded version of this section will lay out where the underlying platforms and research directions are headed over the next several years - which parts of the current toolkit graduate from personal research tools into broader shared infrastructure, which open questions from the publication record are worth a dedicated engineering push, and which engineering practices (observability, reproducibility, data contracts) are being generalized across projects rather than reinvented per repository. The illustration above will be replaced with the final roadmap artwork once that direction is settled.

Most of my engineering principles come from having worked on data that describes real people - patients, cohorts, research participants - long before it became rows in a table. That background makes certain things non-negotiable: sensitive data gets handled with explicit access controls and audit trails, not "we'll get to it later" promises, and a pipeline that cannot explain its own provenance is not trustworthy no matter how good its output looks.

Maintainability is the other constant. Code that only its author can safely change is a liability with a delay timer on it, and documentation that describes what a system does two versions ago is worse than no documentation at all, because it actively misleads. I would rather spend an extra afternoon on a clear interface and an honest README than leave that debt for whoever inherits the system - often enough, that person is me, eighteen months later, with no memory of the clever shortcut I took.

Scientific reproducibility and software engineering discipline turned out to be the same skill wearing different clothes. A result that cannot be rebuilt from raw inputs by someone else is not really a result yet, just a claim; the same containerized, version-controlled, tested rigor that makes a data pipeline trustworthy in production is what makes a research finding trustworthy in a paper. I try not to draw a hard line between the two.

A few thinkers show up in how I approach this, more as working tools than as heroes. Wittgenstein's attention to the limits of language maps directly onto naming things well and writing documentation that means exactly what it says - ambiguity in a spec is a bug, not a style choice. Camus's insistence on working honestly inside an absurd, uncertain world is a fair description of what building on messy real-world data actually feels like: you do not get certainty, you get discipline. And the habit of asking who actually benefits from a given system, and who quietly bears its costs, is a useful lens for thinking about the social impact of the technology I help build - not a political position, just a question worth asking before shipping.

Flagship: 🏳️‍⚧️ | 🏳️‍🌈 | 🇺🇳

Global Burden of Disease is one of the largest ongoing scientific collaborations in public health, coordinating thousands of researchers across nearly every country to produce comparable estimates of disease, injury, and risk-factor burden over time. For a data engineer, it is also a genuinely hard distributed-collaboration problem - reconciling heterogeneous data sources, methods, and reporting standards across institutions that rarely share infrastructure. Participating in that network connects day-to-day pipeline work to public-health decisions made well beyond any single hospital or country.

TransEmpregos works to close the employment gap faced by transgender professionals in Brazil, one of the countries where that gap is widest. The technical need is unglamorous and familiar - reliable data infrastructure so the organization can run, match opportunities, and measure impact - but the outcome is concrete: real people getting a fairer shot at stable employment.

ABRATA (Associação Brasileira de Familiares, Amigos e Portadores de Transtornos Afetivos) works on public awareness and education around mood disorders in Brazil, where mental-health literacy still lags far behind physical-health literacy. Supporting an organization like this is a reminder that not every meaningful contribution has to be technical - sometimes it is simply showing up.

I have spent a long time studying two kinds of structures that grow rather than get assembled: chromatin, and the platforms I build. Both start from something small and rule-bound - a sequence, a schema - and both end up more complex than any single rule predicted, if the underlying constraints were sound. Trees do this too. So do good codebases, on the rare occasions we let them.

A tree's roots are unglamorous and mostly invisible, and that is exactly why they matter. Get the architecture wrong - the data model, the ingestion contracts, the boundaries between systems - and no amount of visible polish above ground will hold. I have watched pipelines that looked finished on a dashboard collapse the first time an upstream schema changed quietly, because nobody had thought about the roots. A platform's roots are its architecture: not the diagram, but the actual set of guarantees the rest of the system is allowed to assume.

Branches are abstractions, and abstractions are a claim about the future - a bet that certain kinds of change will be common and others rare. Good branches grow toward light without breaking under their own weight; good abstractions absorb the variation a system actually encounters without becoming a museum of speculative flexibility nobody uses. I try to grow only the branches a platform's real weather pattern justifies, and prune the rest before they calcify into debt.

Leaves are features - individually small, replaceable, numerous, and that is fine, because that is what leaves are for. No single leaf makes a tree; no single feature makes a platform. What matters is whether the tree keeps producing them, season after season, without straining the structure that holds it up.

Bloom, when it happens, is not a separate event bolted onto the tree. It is what roots, branches, and leaves look like once they have had enough seasons to mature together - the moment a platform stops needing its author in the room to keep functioning, when the same rigor and reproducibility hold whether or not anyone is watching. That is the only kind of engineering maturity I actually trust: not a launch date, but a system that has had time to become itself.

There is a version of this that is purely biological, too. I named a chromatin-analysis tool Bloom for a literal reason - because folding, for DNA as for trees, is how a few meters of raw sequence become something legible enough to regulate a cell, or a genome, or an entire organism's development. The pattern is the same one degree removed: order, at scale, emerging from constraints simple enough to state and rich enough to surprise you. That is the intersection I keep circling back to, whether the raw material is contribution history, transcription-factor binding sites, or four bars of a chord progression that resolve in a way you did not quite predict but immediately trust. Systems allowed to grow honestly tend to end up, eventually, somewhere worth arriving.