Shiny Developer Secrets: Insights From Over 1200 Applicants and What You MUST Know to Shine
Presented by Vedha Viyash Over 1,200 candidates applied for the R/Shiny developer role at Appsilon in the last year, and I will be sharing some insights that we have gained from going through the qualitative and quantitative feedback collected from every round of the interview process. I will be sharing some key takeaways that would help you focus on things that will make you a better Shiny developer. From reactivity to software testing, there are multiple skills that make up a good Shiny developer and you will get to know the major gaps and how to focus on them. Presented at Posit Conference, between Sept 19-20 2023, Learn more at posit.co/conference. -------------------------- Talk Track: Lightning talks. Session Code: TALK-1173
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Hello, everyone. My name is Vedavyash. I work for a company that has a lot of shiny developers across the globe. In one of those markers in the southern part of India, you'll find me sitting in front of my computer, building some shiny apps and programming with R, while occasionally interviewing people to join our team.
Last year, over 1,200 applicants applied for the R Shiny Developer role at Epsilon, and we hired over 30 shiny developers that year. The volume of these candidates has helped us understand what to look for in a shiny developer, and I'll be sharing some tips on how you can become a better shiny developer.
You might call yourself a data scientist, analyst, biostatistician, or any of the hundreds of titles that use R and Shiny, but as soon as you've built your first shiny app, you're a software developer. We've noticed that many of the applicants would greatly benefit from following some good software development practices.
You might call yourself a data scientist, analyst, biostatistician, or any of the hundreds of titles that use R and Shiny, but as soon as you've built your first shiny app, you're a software developer.
For example, can you tell what will be the output of this? If well-written, you can easily do that. How about now? It produces the same output as before, even the functions do the same thing as before. But I hope it explains one of the many ideas about writing code that is maintainable. But all the other ideas are just as simple as this one. It's many small things like these that make up a good developer.
Software testing in Shiny
Let's imagine that you're working in one of our shiny apps from our gallery called Future Forests. This app allows you to visualize the future forest distributions of 12 species under four scenarios. The data source for this app is just a bunch of RDS files with some cryptic names, but the names are not that cryptic once you know what they represent. The prefix of the file name corresponds to a scientific name, while the suffix of the file name corresponds to one of those scenarios.
Let's say you accidentally delete one of these files. Now you should get an error for a very specific selection in the app, while the rest of the app works just fine. So you don't realize that you have an error until someone complains about it.
But now imagine that you have an R script where you check for the existence of a data file for every combination supported by the app. It should give you an error when some file is missing. This is what we call a unit test. And trust me, this will save you from an embarrassment of disconnected from server. I know we've all been there.
You can easily write tests like these using test that and Shiny test two.
Reactive programming
If you check out the function references for Shiny, you'll find over 250 functions listed over there. This can be overwhelming if you're just getting started with Shiny. But I would highly recommend to go through the functions related to reactive programming. Reactive programming is the core concept of Shiny that differentiated from other frameworks.
Again, this seems like a lot of functions, but not really, because the input, output and render functions all behave the same. Again, these functions can be grouped into one of these three shapes based on where they are used in the logic, source, conductor or endpoint. You just need to remember three rules while working with these reactive functions. The shape determines how they can connect with each other. You can connect as many reactive components as you want. Finally, you can also have many to many connections with them. The simpler you make the reactive connections, the easier it would be for a human to interpret it and for Shiny to perform fewer computations to get things done.
The simpler you make the reactive connections, the easier it would be for a human to interpret it and for Shiny to perform fewer computations to get things done.
Software engineering key skills
Finally, I want to highlight a valuable resource that we consider greatly contribute to our team's technical growth, the software engineering key skill sheet. We've put a lot of effort in building this, and we maintain it regularly. This has been instrumental in guiding hundreds of Shiny developers towards their professional development goals. And I hope this will help you find topics and resources as well.