- You have written code to build something in the past.
- You are currently writing code to build something in the present.
- You will continue to write code to build things in the future.
Software developers’ jobs are often defined something like this:
** Software developers use programming to build software that meets the needs of users.**
Let’s break this down:
Software is often meaning a collection of instructions, data, or computer programs that are used to run machines and carry out particular activities – this can include but isn’t limited to:
- Scripts
- Workflows
- Pipelines
- Algorithms and computational methods
Scientific software for cancer research includes all of the above items pretty frequently but scientists often don’t think of themselves as software developers. I think this is in part because they don’t picture that they have users.
But Users can really be anyone! It may start as the person developing the software but may expand to collaborators, random internet strangers, and others in the broader scientific community. The scientific community is full of users!
So in fact, many scientific researchers are doing software development everyday! But many don’t have a computer science degree and many of them have never taken a programming class (That includes me – I’m not sure how I got here!). Self-taught scientific programmers (like myself) may dismiss themselves as being software developers since they often think of programming as a means to an end – a scientific question may be their main goal. But in the pursuit of that goal they are doing software development along the way!
The self-taught nature of many software programmers may also lead them to feel like they don’t know what they are doing when it comes to programming and thus must not actually be software developers. But just because you are new to something, doesn’t mean you aren’t actually performing the skillset and doing the thing!
But perhaps we should start including “software developer” into our identity schemas. Perhaps if we thought of this as one of our many hats we might be able to better adapt what more “traditionally trained” software developers do as a part of their development process. (The Pragmatic Programmer is a pretty big giant for discussing these skill sets and a good read).
What best practices do folks who are full-time “traditional” software developers use to do their work? This is where multidiscplinary bridges built between fields will really come in handy.
I learned the most about software development when I worked in a lab that was very multidiscplinary and included computer scientists, user experience designers, back-end developers, and front-end developers. Each of these individuals had their own special skill sets that we could all benefit from learning from each other about. Any given individual can’t possibly be an expert in all of these tasks, but if we all are doing a bit of software development, we should definitely try to learn from folks who might have been doing this work a bit longer. Then we can use our scientific knowledge and expertise to apply skills we learn from others to new applications!
And this type of multidisciplinary collaboration is my favorite part about science! But warning, to fully utilize this kind of collaboration requires a lot of soft skills development…
Examples:
- Clear communication that is tailored to your audience.
- Humility to recognize when something is outside your realm of knowledge.
- Honesty and confidence to admit you don’t know and that is okay!
- Patience to figure out communication with each other.
…. And soft skills are actually really hardest but are really the foundation of everything else going smoothly!
In conclusion: You’re a wizard software developer, Harry
Acknowledgements to Sean Kross for inspiring this blog post in a conversation I had with him.
R version 4.3.1 (2023-06-16)
Platform: x86_64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.5.2
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib; LAPACK version 3.11.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
time zone: America/New_York
tzcode source: internal
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] vctrs_0.6.5 httr_1.4.7 cli_3.6.2 knitr_1.45
[5] rlang_1.1.2 xfun_0.41 jsonlite_1.8.8 glue_1.6.2
[9] openssl_2.1.1 askpass_1.2.0 htmltools_0.5.7 hms_1.1.3
[13] fansi_1.0.6 rmarkdown_2.25 evaluate_0.23 tibble_3.2.1
[17] tzdb_0.4.0 fastmap_1.1.1 yaml_2.3.8 lifecycle_1.0.4
[21] compiler_4.3.1 ottrpal_1.2 fs_1.6.3 htmlwidgets_1.6.2
[25] pkgconfig_2.0.3 rstudioapi_0.15.0 digest_0.6.33 R6_2.5.1
[29] utf8_1.2.4 readr_2.1.4 pillar_1.9.0 magrittr_2.0.3
[33] tools_4.3.1 xml2_1.3.6