Challenge your instinct to dive straight into the code
Every time a new bioinformatician joins a team, I see the same pattern. The first questions are almost always technical.
What is the best aligner for this dataset? How do we optimize runtime? Which workflow engine is the team using?
These are good questions. They show curiosity and technical drive. But they miss the larger reality of what makes bioinformatics succeed or fail. A pipeline succeeds not just because of the code behind it, but because of the ecosystem it lives in: the infrastructure, the people who run it, and the systems that keep it reproducible over time.
Over the years I have seen many new hires focus on which package to import or which tool is fastest. Those choices matter, but the real challenge is understanding the infrastructure that supports everything else.
Here are the five mindset shifts I wish every new bioinformatics hire made early.
1. Your Pipeline Is Part of a System
It is tempting to think of your pipeline as a single piece of code. But it is never just that. It includes containers, parameters, references, data lineage, run history, and all the people who will interact with it after you move on.
I once worked with a team that had excellent scripts but no consistent containerization. Every developer had their own version of the environment, so the same code could produce slightly different results depending on who ran it. Eventually a regulatory reviewer asked for verification of a published result, and we could not reproduce it exactly. The science itself was not wrong, but the infrastructure gaps eroded confidence.
When you treat your pipeline as part of a system, you build with those pieces in mind. You are not just delivering code. You are delivering something that survives handoffs, audits, and reanalysis. Tools like Docker, Singularity, Nextflow, Snakemake, or WDL help by enforcing that context – turning what could be a fragile script into a reusable process.
2. Don’t Treat Infrastructure Like a Black Box
Most new hires are handed workflow engines, schedulers, and containers they have never touched before. It is easy to take them for granted. “It runs” becomes good enough.
Until it doesn’t.
A junior teammate once asked why their jobs kept failing on the cluster even though the code was correct. The issue was not the code. It was that the scheduler had queue limits they did not understand, and their jobs were getting killed silently. They lost days before surfacing the problem.
The lesson is simple. If you are using something, learn the basics of how it works. You do not need to master Kubernetes, SLURM, or Docker on day one, but you should understand the knobs and levers well enough to debug when things fail. Otherwise every roadblock turns into a ticket for someone else, and your progress stops until they have time to look at it. The same goes for workflow managers like Cromwell or Snakemake. Knowing how they handle failures, retries, and logging can save you weeks of frustration.
3. Documentation Is a Deliverable
Too many pipelines live only in the head of the person who wrote them. When that person leaves, so does the pipeline.
Documentation is not extra credit. It is part of the job. The fastest way to test whether your pipeline is ready is to hand it to a colleague and see if they can run it without your help. If they cannot, then you are not done.
I have seen projects grind to a halt because the one person who knew how a key workflow ran took a two-week vacation. Even worse, I have seen teams abandon promising analyses entirely because no one could figure out how the original scripts were wired together. That is wasted science.
Good documentation does not need to be elegant. It just needs to be clear, up to date, and tested by someone other than you. A simple README in GitHub, well-commented config files, or a workflow definition checked into version control can be the difference between a reproducible pipeline and a lost one.
4. Every Quick Fix Becomes Someone Else’s Problem
Early in your career, you will feel pressure to get results fast. A hardcoded path here. An undocumented parameter there. It feels like you’re being efficient in the moment.
But quick fixes always have a long tail. I once traced a subtle error in a clinical pipeline back to a hardcoded genome reference that had been used in a one-off analysis two years earlier. No one noticed at the time. By the time it surfaced, it had impacted dozens of downstream analyses. The original author had long since moved on.
When you write infrastructure, think in months and teams, not hours and runs. The small shortcuts you take today will become technical debt for someone else. This is why version pinning in Conda, container hashes, or explicit reference management in DVC or LakeFS are worth the upfront effort: they make sure tomorrow’s runs behave the same as today’s.
5. Ask Questions Early
One of the most damaging mistakes a new hire can make is to stay silent. You are not expected to know everything. You are expected to build things that others can rely on.
I once had a junior bioinformatician who admitted after six months that they had been manually rerunning failed jobs instead of asking for help with the scheduler. They were exhausted, the pipeline was brittle, and the team had lost valuable time. A single early question could have prevented months of wasted effort.
Asking questions is not a weakness. It is how you build reliability and trust. Whether it is about why parameters live in a config file, how S3 paths are managed, or how the workflow engine handles retries, surfacing uncertainty early prevents bad habits from calcifying into systemic problems.
Bioinformatics Is About Trust
At its core, bioinformatics is not just about building pipelines. It is about building trust.
Trust that your results are reproducible.
Trust that pipelines will still work months or years later.
Trust that teammates can build on each other’s work without guesswork or archaeology.
When you join a new team, remember that your work lives longer than your code. Every decision you make contributes to or erodes that trust.
The best bioinformaticians are not the ones who know every algorithm. They are the ones who understand that infrastructure is not a black box, that documentation is a key deliverable, and that reproducibility is as important as results.
And while individual habits matter, the strongest systems do not leave these things to chance. That is why we built Via Foundry: to make trust the default. Containers, parameters, lineage, and run history are captured automatically, so teams can rely on results years later without wondering what went missing.
When you ask yourself, “How do I get this analysis done?” stop and ask a second question. “How do I make sure this analysis can be trusted, reproduced, and extended after me?”
That shift in mindset is what turns code into infrastructure, and infrastructure into science that lasts.
