Getting something out of the model
Every stage of work has something that comes out of it. In a software program, a line of code will usually produce something the next line will consume.
However, in the context of programming for science, there are tangible things we often think of as output - often the discrete, visible outcomes of a project. This includes such things as datasets, graphs, charts, images, written papers etc.
Communicating knowledge
As much as it would be nice to devote the majority of our time to working on the scientific core of a project, communicating understanding about a project is crucial.
Creating output is about turning your code, and other intimate details of your knowledge, into something consumable for those in that wider world.
A definition?
A precise definition of output is not especially important. It'll only have meaning as a function of context and purpose. Practically, a lot of project code ends up producing or facilitating output: Reorganizing datasets, producing charts and graphics etc. It's up to you as to where you draw the line in your own projects.
What's required
A constant for output is change. What you need your output to do will change throughout the life of a project.
At the start, output is more often about exploring your implementation. Perhaps producing rudimentary graphs to test a potential solution early on.
Later, requirements for output will shift to producing specific and presentable documents to communicate with those outside the project, or those you report to.
Algorithms, recipes, presentation
The presentation of output matters a lot. It'll go further if it looks good.
Imagine a research process as you might bake a cake. You gather the ingredients (input), combine them (the model or algorithm) and the finished product is the cake (the output).
Baking a cake that tastes great is enough of a challenge, and a great tasting cake goes along way, but how it looks will change the perception of its quality.
Changing perception might even enhance the taste. Logistics matters as well. What's the cake for? A wedding? A birthday? Is it getting sliced and handed out quickly or is it mostly for looking at?
Similar questions must be answered in the programming and research context. You need to know who's going to be using the output, and how.
Marketing... ?
It's critical to understand that your project output covers a lot of ground in marketing your work. In tight-knit circles, this may be less a consideration, but don't count on it.
Care, attention and flaire in the visible products of your work can make all the difference in generating interest and getting people to take a closer look - even within your own organization. Amazing work without simple access points doesn't often go far.
Distilling ideas is hard work
Quality of output is certainly not just a visible characteristic. Reducing an idea to the communicable essentials - simple but not too simple - is a challenging and time-consuming task.
Being able to communicate ideas, visually or verbally, often takes considerable effort to get right. Remember it's not about being fancy, or overwhelming your audience with animations. This kind of thing is definitely an anti-pattern!
This looks really nice and this is a great explanation are both important ways to have your output described.
I didn't sign up for this!
It's been said that writing the first 90% of a software program takes 90% of the time, while the last 10% takes 90% of the time. Not true for research.
It's more like: Getting your data into a useable form takes 270% of the time, writing code takes 90% of the time, and generating output the final 90% of the time. It's a good bet the adage can be applied recursively. In fact, pretty much count on it!
I'll come back to the struggle with data in the future, suffice to say, while messing around with your data is arduous it's usually one of the first things you'll get into and at this early stage you still have hope for the future.
Generating public-ready output at the end of a project can be exhausting because it's usually uninteresting, painstaking work. Unfortunately, it's uninteresting work that's critical to the success of your project.
Part of the job
If this is all new to you, it can also seem somewhat superflous to the immediacy and interest of science. Unfortunately (for you) you'll have to accept that people are going to care about the presentation of your work, no matter the quality of the ingredients and effort, and this will matter a lot to your career.
Interested experts
Usually only those with the most intimate understanding of a problem and project (and the willingness to engage), can recognize the value of work without having useable access points.
Getting all of this right is a grind, and can take up a lot of your time in non-trivial projects. Being aware of this fact, and accepting this work as critical to the outcome is important to a successful project.
Output is a first class citizen
Managing the lifecycle of output in a project is really about recognizing it as a first-class citizen of the project. This means you give (well, nearly) as much consideration to how you'll present the work as the work itself.
This is, of course, terribly annoying for the person who has deep familiarity with the subject because it's painstaking to generate effective, high-quality output. It's about communicating, and it's necessary.
Good software practices are important for any additional code that produces output. Things like separation of concerns, clear interfaces and testing, perhaps. It's also an iterative process.
Don't treat this part of the project casually. Rarely is the first iteration of your project the one that survives. You can burn up a lot of time treating the production of output in a haphazard manner.