Lead (and Be Led By) a Team of Student Developers (Presentation at GusDay 2023)

By Chad Kluck on

This is based on a presentation I gave at GusDay 2023 held at St. Olaf College in Northfield, Minnesota, titled “Lead (and be Led by) a Team of Student Developers.” Links to presentation materials and resources are at the bottom of the post. A 50 minute presentation video also follows at the end of the post.

Chad Kluck, Software Engineer, University of St. Thomas

Introduction

With so many systems, languages, and platforms in play, managing and collaborating with student developers in a full-stack development environment often seems like more work than it’s worth--especially when there is only one developer on staff! How do you hire, train, and mentor student developers to collaborate and complete high-value, high-impact projects and be a leader in innovation themselves?

Here are the tips, tricks, and examples of the structure I used to set student developers, and myself, up for success in the University of St. Thomas Library Digital Services department.

The University of St. Thomas is the largest private university in Minnesota, with over 9,000 undergraduate and graduate students. I’ve been a full-time employee there for 21 years, and before that, I held various student positions with some fantastic supervisors who empowered me to innovate and lead special projects. As a staff member, I’ve worked as a Systems Specialist in the Career Development Center, Web Developer in the University Libraries. In April 2023, I transitioned to a Software Engineer role in Innovation and Technology Services. As an alumnus of the undergraduate Computer Science and Graduate Software Engineering, I am familiar with the curriculum, faculty, and students of the programs.

Before I go over the background of how I supervised students, I want you to reflect if any of these statements sound familiar:

  • Hiring student developers takes too much time in management, training, and provisioning.
  • Instead of getting stuff off your plate, you’re dealing with timecards and HR stuff, supervising, answering questions, and troubleshooting yarn, grunt, git, access credentials, AWS, Docker, Java, and PHP development environments.
  • A new project comes along, but you have no time to train, set up a development environment, or provision access.
  • After graduation, you’re left with technical debt as you try to fit non-production, undocumented, not real-world tested code into production. (Well, it worked on your student’s machine for their demo during Finals Week!)
  • You go through the process of providing access to many systems only to have the student leave for a better, higher-paying campus job.

That was me a few years ago. Since then, I re-thought the way I hired, trained, and delegated projects to student employees by:

  • Focus and scope the position (leave room for growth)
  • Hire the right students (know what you need from them)
  • Provide structure (schedules, communication, and expectations)
  • Competencies for advancement (with pay increases!)
  • Development guidelines (with room to grow!)
  • Learning opportunities (for them and me!)

I learned I didn’t need to set up a complete development environment for students to work within. That was a project they were more than capable of completing alongside a development project! I established boundaries and expectations and expanded them as they and I progressed. Once I began to make them fully responsible for learning and evolving a core set of projects, inside and out, challenging and improving processes, I set them up to succeed and leave the web application infrastructure better than they found it. Better yet, they gained hands-on experience in creating and deploying production-ready applications. (Under my supervision, of course!)

When the mentor and mentee both learn, hiring students can be the most rewarding experience on the job!

Background

The Start

I began separating various parts of my Web Developer position in the library in 2017. From experience, I knew I couldn’t hire a student who could do everything I did. Instead, they would specialize in a particular aspect of my job.

At the time, I was responsible for:

  • Marketing, social media, and web content (blogs, events, and images).
  • System administration.
  • Physical space technology, such as study rooms and the scheduling system. (Not labs, thankfully)
  • Analytics, mainly web, but also extended to other functional areas.
  • Web and Application Development.

You can guess which one I had the least time for: Web and Application Development.

However, that was not the first position I decided to hire students for. I instead went with the most time-consuming task of Marketing, social media, and web content. Why? Because if I didn’t have time for web development, I wouldn’t be a good web development supervisor. Many things digital came under my purview; marketing was the least related to a web developer, took the most time, and, quite frankly, would require very little training of students. Facebook, Twitter, Instagram, and Canva? If I needed to train students on those, I hired the wrong student!

Also, students were best suited to marketing to their peers, so I gave them full responsibility to take marketing requests from staff, develop multi-channel marketing campaigns, learn branding and inclusive design, and only run things by me for final approval before posting. They were in control, had full responsibility, and worked directly with their “clients,” consisting of staff internal and external to the library. They were also responsible for organizing photo and video shoots with the campus photographer.

Developer Student Assistant

By 2019 I was supervising two marketing students and had enough “free time” to hire a third student, this one for web development. (By “free time,” I mean the marketing students were self-sufficient, allowing me to focus some supervision time on a new position.)

I had hired technical students in the past while working in the Career Development Center and quickly switched to hiring and supervising media and marketing students. Hiring students who could design marketing materials and post on social media was easy. Computer science students, however, came from various backgrounds, and Java application development was still the primary skill being taught. Front-end and back-end web development wasn’t something many candidates had experience with. Web development at the time was self-taught.

I hired my first developer for the library in the spring of 2019. The interview went well; the candidate answered all the questions to my satisfaction and performed the code walkthrough flawlessly (more on the interview process later). However, when it came to coding, it didn’t work out, and after a few one-on-one sessions, I let him go.

When the next development student started in the fall of 2019, we were sending code back and forth via ZIP files as we were on a LAMP (Linux, Apache, MySQL, PHP) stack, and I had to upload changes to the server via SFTP (Secure File Transfer Protocol).

It was a small shop, just PHP, JavaScript, HTML, and CSS. However, I saw the rise of new integration projects over the horizon as I was granted development access to the university portal site and Canvas LMS (Learning Management System). Not only were ZIP files becoming too hard to keep track of, but the number of systems and integrations grew, many requiring new training, development environments, and workflows. Even new production environments emerged as we were now putting assets in the cloud on AWS.

It was overwhelming. The whole development infrastructure needed to change since I was no longer a team of one. I was now part of a collaborative team, and any change management or production workflows that seemed silly and overkill on a one-person team were now imperative.

However, implementing change management, deployment mechanisms, keeping track of documentation, and ensuring things didn’t break upstream needed infrastructure.

So, over the next three years, piece by piece, my students and I developed ways to create a collaborative and automated environment.

As my student automated build processes, I created code repositories in the fall of 2019. I dove into CI/CD pipelines and automated the build and deployment process. We documented development environments for Grunt, Node, AWS CLI, PHP, and Git. We tested the documentation, ensuring it worked on various Windows and Macs around the office.

We now had a way to share our code and replicate robust environments—the hardest thing to manage until this point was obtaining and configuring enough workspaces for three students. There was only one workstation near my office, and we set up another on a different floor of the library. I’ve always dreaded setting up IDEs and command-line environments, but our work on this front made it bearable.

And then, spring of 2020.

My three students and I moved to remote work.

And my department of one had its most productive year since I started.

Setting up collaborative SharePoint sites, Teams messaging, code repositories, and development environments, all our work before the pandemic paid off. And my students were learning a new life skill: work-from-home and coping with emotions in a world turned upside down.

We frequently met via Teams and Zoom, sent questions and updates back and forth in chat, and communicated more than ever since it was the “new normal.”

I had time to learn how to develop serverless applications. My marketing students were independent enough to apply branding templates and continue social media. The student developer was building the infrastructure to expand our development environment further. We frequently met to do code walk-throughs while screen sharing via Microsoft Teams, something we both enjoyed far more online than in person. He introduced me to additional Node build packages; I introduced him to continuous integration and deployment concepts, and we built on what each of us was learning.

In the fall of 2021, I hired a second developer, bringing our team to four students (two developers and two marketing) plus me. I also hired a marketing student to fill the position left open by a student who graduated, meaning there were two new students to train, each in separate positions.

Onboarding was much easier since I had established students who could train the new hires in both positions. The developer student could also assist in setting up the new student’s development environment. (Coincidently, I was absent the last three start dates due to a medical emergency fall of 2021, COVID spring of 2022, and another round of sickness fall of 2022. It was nice having the veteran students take over.)

By the end of the summer of 2022, I had completed establishing hiring, onboarding, work structure, development guidelines, and developer competencies and advancement paths. It was all done in time to hire a new student in the fall of 2022 to replace another that graduated.

Also, marketing supervision transitioned to another staff member to remove marketing and content responsibilities from my position so I could focus more on development.

I was now supervising just two students, both developers, during a website redesign which required me to learn a new CMS and development framework. One student was focused on back-end development, and I set the new student on front-end development projects. It didn’t take long, and she was able to quickly explore and implement new methods for deploying a microsite and creating a test area for the new CMS framework. The following spring, I promoted her to Level 2 where she ended up developing two Vue.js components on her own before graduating.

Results

I’ve now supervised five marketing students and four student developers in the library.

By offloading social media and marketing and hiring two developers focused on critical areas, what used to be a department of one:

  • Developed three serverless web applications with a combined 2 million requests per month
  • Tripled the number of in-house RESTful APIs
  • Created an automated deployment pipeline for static JavaScript and CSS assets serving seven websites
  • Set up both Sandbox and Production Environments on AWS with appropriate access provisioning
  • Completed a website migration with five new Vue.js components
  • Developed CI/CD (Continuous Integration/Continuous Deployment) for serverless applications.
  • Documentation and implementation of our first tests.
  • Created three AngularJS widgets for the university portal providing personalized content for students and faculty
  • Documented a majority of our procedures

Supervision Structure

I will focus on student developers since I no longer supervise marketing students.

Hire the Right Candidate(s)

In the job description for the Developer Student Assistant, I put in the library’s development statement:

The library strives to promote the ever-moving forward best practices in usability, accessibility, security, testing, documentation, and deployment to prepare our student developers for internships and jobs within the industry. In addition, we foster a caring and inclusive learning environment that aims to support all who use library services.

We seek a punctual, self-driven, reliable student to work a consistent schedule of 5-10 hours per week. The ideal candidate possesses experience with CSS, HTML, JavaScript, PHP (or Node.js), and Python. Has an interest in learning and implementing accessibility and usability standards, automation of code testing and deployment, and cloud development in AWS.

This exciting opportunity will provide on-the-job training for gaining real-world experience with UI/UX/Accessibility best practices, Git repositories, and automated deployments while developing front-end (JavaScript/Angular/Vue/jQuery, CSS, HTML), back-end (PHP, Node.js, Python), and Dev-Ops AWS architecture (CloudFormation, CI/CD, Serverless, storage, and automation).

While the statements themselves don’t filter out candidates who won’t meet my criteria, it should get those who have experience and are looking for more than HTML and content management to apply.

Regarding screening, I looked at projects and internships beyond the classroom. I was more interested in CSS, HTML, and JavaScript as that is where the student would start (more on that later). I wanted to find qualities that let me know they could read code, solve problems, and work and learn independently.

If I could, I prioritized development experience over content editing. Development experience (personal, class, or work) included APIs, JavaScript, JS frameworks, and CSS, not just a personal website.

When it came to the interviews, there were about six behavioral questions and four code walk-throughs.

With the behavioral questions, I wanted to know how they problem-solved, communicated with their supervisor, and received feedback. I always ask, “Tell me about a time you made a mistake.”

I want students who have made mistakes and can explain how they worked to resolve them. How did they communicate with their supervisor? How did they recover? What did they learn? Sadly, I once had a candidate emotionally shut down, stating they wouldn’t know what to do if they made a mistake. Candidates must be willing to learn from mistakes and failures, and if they haven’t made a mistake or failed, I didn’t think they were ready to fill the position where success only comes at the end of a project filled with trial and error.

I’m not a big believer in code tests and prefer code walk-throughs. The central portion of this job is to break down and understand existing code and effectively explain what it is doing.

Some were pseudo code, and some were JavaScript and CSS. I had simple examples of loops, arrays, and functions. I would give them a minute to review the code before them and then walk me through the order of execution and variable values.

I wasn’t so concerned about them getting it 100% correct, as semester to semester, I even fumbled a bit as I brushed up before the interviews. I was looking for what they picked up on as the code samples, though simple, seemed to reveal themselves differently to different candidates.

The best I can explain it is like a multi-generational joke on The Simpsons. If you had three generations of people in a room watching an episode, all three generations would laugh at the same joke but for different reasons.

Many code samples incorporated basic, advanced, and “expert” components, which could be walked through at a basic level, while the more advanced components hid in plain sight.

If a student seemed to get stuck, I would gradually drop a hint here and there, looking to see how they recovered. I was always hoping they would recover, and if they did get nervous, I would just nudge them along as needed, explaining what an object was or how the loop executed one more time before exiting or the difference between the dot class or hash id notation in CSS. I also didn’t mind if the candidate asked questions—since they would need to be willing to ask in the actual position.

Ultimately, I was looking for a good attitude, learning experiences, and the ability to read basic HTML, CSS, and JavaScript.

Onboard and Instill Structure, Confidence, and Independence

  1. Communication
  2. Work Hours
  3. Safe Working Environment/Workplace Harassment
  4. Empowerment and Independence
  5. Training
  6. Code Reviews and Mentorship

On day one, I set out to cover any fears or initial questions the student may have. I also hoped that it would instill the power, confidence, and structure they were expected to maintain while in the position.

Communication

Communication was done via Microsoft Teams chat. I promised to email only HR and scheduling communications. They could send me an email or Teams chat anytime, but I would only initiate a chat during their work hours. They had to “check-in/check-out” with me via Teams so I knew if they were in or out. It also helped them to keep a record for filling out their timesheet.

In the past, I had a few students drop off the face of the earth. I made sure to let them know that it was okay if school or personal lives got complex. I didn’t need to know all the details, but if they needed some time away or cut back hours to please, please, PLEASE communicate. Taking time for mental health is essential.

Work Hours

Shifts were just a way to set aside time. It was recommended to keep a set schedule, but it could be adjusted. Since it wasn’t a service desk and there was flexibility, they could rearrange a little, but they had to let me know. Everything was okay if they checked in, did their work, and met deadlines.

Mid-terms, finals, and spring break were optional work weeks. During the summer, I encouraged off-campus internships. Students always brought back real-world developer experience to incorporate into our projects.

Safety

I stressed that I would uphold a safe working environment free from discrimination and harassment. While the main culprit could be the comments section on social media posts, I ensured they understood I would take it seriously if they ever felt uncomfortable. I would stand up, back them up, or do whatever needed to be done to take care of the situation. If, for some reason, I was the issue, I gave them additional staff contacts to bring the matter to.

Empowerment

I let the students lead the projects and didn’t get in their way. I provided guard rails but let them bring fresh, innovative eyes.

Staff making requests were their clients. It was up to my students to reach out to them, get requirements, and present drafts and the final product for feedback. If they were having difficulty receiving information in a timely fashion from a staff member, I had the student CC me on an email. That usually got the staff member’s attention and a quick response! I was just an observer. If I needed to discuss something with the student, I did it between the student and me, not in front of the other staff member.

Training

We have various digital badges available through our St. Thomas E-Learning and Research Center (STELAR), one of which I required of both the marketing and developer students: Digital Accessibility Basics. It is a self-paced course that takes about 1-3 hours to complete. It stresses the importance of producing accessible content with ALT attributes, proper headings and page structure, contrast, and video and audio.

I also introduce the students to the DEI Viewfinder, a tool at the university, which is mainly marketing focused, but just like accessibility, opens the students’ minds as they look beyond their own experiences and consider the experiences of those that interact with their designs.

The university also has a branding and style toolkit I walked the students through.

Finally, I permitted them to perform research on the job:

Since this is an advanced position, students are expected to come with some knowledge of their area. Quick reference of online tutorials, how-to, W3C, Stack Exchange, etc., is acceptable daily. Lengthy tutorials should only be used when assigned tasks requiring research as approved by your supervisor.

Two books I made available to the developers were:

They will need a sandbox environment to learn, experiment, and prototype in.

Status Updates, Code Reviews, and Mentorship

In addition to the students checking in at the start and end of their day, I had them add status updates to a simple development tracking system. It was a simple SharePoint list widget that listed the project name, whom it was assigned to, the description of work, and the ability to add comments to the project as status updates.

I would automatically receive any comments via email and review them to keep up to date with the student’s progress. Comments didn’t have to be too detailed; they could read more like commit messages or if there was a bug they were trying to track down, or feature they were researching, or even notes to themselves about what they should remember or do on their next shift.

If there were anything I could respond to, I would add another comment.

This helped because students could research independently and ask questions without feeling like they were bugging me or giving up too early. If I saw they were stuck, I could step in, but typically they were able to answer their own questions on the next shift.

Once I saw that a significant component was complete, I requested a time to do a code review. Typically, when they checked in for their shift, I would ask if they were available for a review in about half an hour or so. We would then start a video call via Teams, have a brief, casual conversation, and then screen share and go through the code.

If there was anything to optimize or some reference code I could point to, I would take the opportunity to offer suggestions after the review so I wouldn’t interrupt them. We’d then go back to the points I noted and review again. If I didn’t understand something, I would have them re-explain it at that moment. There was no use continuing if I was utterly lost. (It happened a few times, but the student got me back on track quickly!)

Sometimes they didn’t have code to review, but they were researching and experimenting with a new resource or method, so they would explain and teach me what they had discovered. They often implemented a process I had never done before, which was a learning experience for me!

Once we had completed their code review and I had the chance to learn from them, it was now my turn to share what I was working on. I typically choose to show them projects or portions of a project that related to what they were currently working on. If I knew their next step was to grab secrets from a parameter store, I’d show them how I did it. If there were higher-level concepts to go over, I’d explain them.

Technology Statement and Guidelines

Sometimes we don’t get a choice in the framework we use. We contract with a vendor, and their developers’ kit for UI and custom components might be AngularJS. No, not version 16, but 1.6.

When you code an application from scratch, you get to choose the framework based on picking the correct set of tools for the job rather than just sticking with what you or a hired developer knows.

And each college student, each with their own learning and experience path, can quickly introduce many different frameworks that you will be responsible for learning and maintaining once they graduate. It also adds to the list of qualifications when posting the position to hire the next candidate.

In Responsible JavaScript by Jeremy Wagner, a chapter at the very beginning goes over choosing an architecture. Wagner refers to the A11Y Project’s technology statement about their choice of what to use when developing.

The A11Y project declares in its Technology Statement:

This is a deliberate choice intended to balance:
  • Accessibility and interoperability.
  • Ease of setup.
  • Approachability for beginners.
  • Cross-Operating System and browser support.
  • Local and end-user performance.

When working on the website, please be sure to utilize these technology choices first, and stay with them if at all possible. Honoring these technology choices helps to keep the site easier to maintain.

I added a sixth bullet point:

  • University-wide staffing expertise.

Following their lead, I looked over what we had in the library and came up with my own:

  • Pure JavaScript
  • Twig, Vue.js, SCSS (Cascade site)
  • Angular.js v1.8 (Primo Customizer and One St. Thomas)
  • Gulp (Primo Customizer)
  • jQuery and Bootstrap (Springshare)
  • WAI-ARIA
  • JSON
  • CSS
  • Git
  • Bash
  • Markdown
  • JS Doc
  • Model-View-Controller patterns

This list covers the front end and specifies frameworks used in relation to the specific sites. In the library’s development environment we wouldn’t start a brand new project from scratch using jQuery, Bootstrap, or AngularJS. We also won’t start writing React components for Primo Customizer and Springshare.

Everyone’s list will be different, but I highly recommend pure, vanilla JavaScript to be considered. There are a lot of small projects that do not need a framework, it is a great training tool, and a good, solid understanding of JavaScript will improve the way frameworks are used. I have another list for the back-end and another for deploy pipelines.

I made sure it followed the five bullet points outlined by A11Y as I couldn’t argue with the first three points relating to Accessibility, ease of setup, and approachability for beginners.

Most tools should be familiar if someone from the university’s development team needs to step in.

I further state that our foundation is built on the following:

  1. Microservice architecture
  2. Asynchronous execution
  3. Serverless and Code-less
  4. Security
  5. Infrastructure as Code
  6. Continuous Integration/Continuous Deploy

I also specified that each repository must have a README that explains any necessary development environment set-up and examples of use. Any API service must have an accompanying Swagger/OpenAPI document, usage of JS Doc, and an overview of the AWS Well-Architected Framework.

Not only did this document document my job, but it also provided guidance for the students to learn from and reference on their own as they set out to complete projects. With it, I could say, “Refer to the Technology Statement,” and let them explore the resources independently.

It provided training material not only for the student position but also for real-life industry best practices. If they dug into microservices, security, infrastructure as code, and the concepts in the Well-Architected Framework, they were building their resume and skills they could sell at interviews.

The Technology Statement and Guidelines document grew to 29 pages, covering the development environments, production deployments, git procedures, code samples, timestamp requirements, etc. Writing took me about nine months, and I still don’t consider it complete. As our technology evolves, the guidelines will continue to be updated with the help of the students because it is their document as much as mine.

Three pages would be a good starting point, and let your students help expand as they research and implement new technology. They will know first-hand what the next student needs to know.

I didn’t expect the students to read the Technology Statement and Guidelines one night or during the semester. It was there as a reference, so I wouldn’t put too much time into the first draft beyond listing essential tools.

Developer Competencies

To create a training path, I outlined exactly what I would be hiring new students for, what languages and tools they were responsible for, and how they could advance in the position.

The very start began much like the job postings:

The Web Developer Student Assistant position exists to support the Library Web Developer in designing and implementing web technologies that help connect our users with information and services that improve the library user experience.

Library Digital Services seeks to hire, train, and retain talent. We strive to promote the ever-moving forward best practices in usability, accessibility, security, testing, documentation, and deployment to prepare students for internships and jobs within the industry. In addition, we foster a caring and inclusive learning environment that aims to support all who use library services.

The University of St. Thomas Libraries Digital Services puts much effort into setting up development environments and training new student hires. As such, we want to ensure students utilize their skills for the common good, advance the library, and learn practical, real-world skills they can use upon entering the workforce.

It also includes advancement levels, each with a pay raise.

  • Developer Level I: New hires with basic front-end focus (JS, CSS, and HTML)
  • Developer Level II: Advanced front-end focus (Frameworks such as Vue, Angular, React)
  • Developer Level III: Student choice: Expert front-end or learn back-end (AWS Serverless)
  • Developer Level IV: Student choice: Pay increase and a possible switch to front-end/back-end

Students may advance no more than one level before the start of each semester. I don’t have any levels provisioned beyond level four, but I provide merit increases each semester.

Before advancing to the next level, they must demonstrate competency at their current level. For example, Level I:

Students should be able to write accessible, secure, maintainable, efficient, and well-documented code within a development environment utilizing GIT, JEST, and GULP, ready to be integrated and deployed via a CI/CD pipeline.
  1. After hire, further demonstrates an ability to read, understand, and write JavaScript, HTML, and CSS
  2. Able to set up a development environment (AWS CLI, GIT)
  3. Can demonstrate an ability to work autonomously, perform research, ask clarifying questions as needed, and communicate with the supervisor as described in the Digital Services Student Worker Expectations document
  4. Understanding of the St. Thomas Libraries static asset environment:
    • Able to upload and organize images and files in S3
    • Able to maintain, manage, and push code in the static asset repository using GIT
  5. Complete and earn a badge for St. Thomas’s “Digital Accessibilities Basics” training through Canvas
  6. Practices good habits of logging daily progress in the Dev Tracker
  7. Demonstrates ability to apply best practices for creating accessible web components. Able to refer to in-house and ARIA code templates and implement accessible features. Can run accessibility checks and coordinate user tests with accessibility contacts in MIC and ITS
  8. Able to use basic JavaScript security principles such as scope and input validation.
  9. Demonstrate an understanding of writing test code using JEST
  10. Demonstrate an understanding of the GULP manifest for creating site-specific JS/CSS packages
  11. Demonstrate an understanding of setting up a new CodeCommit Repo and Amplify project in Sandbox

Termination may result at any time based on expectations outlined in the Digital Services Student Worker Expectations document.

Also, if a new hire at Level I cannot make adequate progress by completing Step 4 by their fifth week (or 40 work hours, whichever comes first), their employment may be terminated.

The library development environment is fast-paced, with many projects requiring increased technical skills. Therefore, advancement is imperative to keep projects on track and divide and assign tasks to assist the Library Web Developer. After two terms, the supervisor must take corrective action if the student cannot advance to the next level.

  • The supervisor will meet with the student to develop and implement a plan of action outlining goals to get the student on track for advancement.
  • Employment will be terminated if the student and/or supervisor do not feel the student has made or can make adequate progress toward the goals outlined in the action plan.

Evaluations

With the expectations laid out in the initial training, the guidelines, and the advancement, my students clearly understood what they needed to do to succeed. I also had a straightforward method to evaluate their progress and justify any raises or additional hours to my superiors.

It set the students up for success because they had clear documentation and defined limits, allowing them to focus on a small set of skills before moving on to more advanced projects. They could also advance independently as they had a self-guided professional development course.

It helped with my time because I could gradually train and provision access and not have to dump all my knowledge at once. I also clearly understood what projects should be assigned to what students.

Summary

As each student has graduated, I heard from them how much they learned and appreciated the work under my guidance. I also repeatedly expressed my gratitude because if not for their research, experimentation, hard work, and unique skills, the library’s development infrastructure would still be zip files being passed around via email.

We were able to develop infrastructure and add a whole new set of skills alongside the projects we completed, making future projects more manageable.

From start to finish, it took about a year when I really started to put effort into documenting my process and developing a hiring and training framework. Creating the environments the library now has on AWS took about three years, but I was diving head-first into cloud architecture at the same time. With the environments in the library, it should be a relatively straightforward process for my successor to pick up where I left off, whether they hire students immediately or not.

As for me, all the students that worked for me have graduated, and I now have the process of tailoring the student employment structure to the unique characteristics of my new position in my new department. However, it doesn’t have to be perfect as I start over. I have everything I shared here as a starting point and can’t wait until I begin to rebuild in the fall.

Mentoring students in a development environment is one of the best things about my job in a university environment.

Resources

Additional Downloads

Training Resources

Workplace Management

GusDay 2023 Presentation

The following video is based on the presentation given at GusDay and uses the presentation slides. Closed captions are available.

Comments

View comments, reply, like, or share this post on:

Tags