Passing on Skills and Knowledge Programmer Training at the University of Texas at Austin 1. 2. 3. 4. 5.

Introduction History of the training program Going through the training program Continuing education Conclusion

Introduction With over 50,000 students, The University of Texas at Austin is one of the largest universities in the country. Running a university of this size requires many business processes. The University has its own police department, it generates its own power and cooling, and it manages its own telecommunications systems. Fifteen residence halls house and feed thousands of students (one of these halls has a population higher than over twenty Texas counties) and the Student Health Center provides medical services for much of the student body. As with any organization, the University has HR, payroll, and other financial processes. Most of these processes, as well as education-specific processes such as maintaining records of student enrollment, transcripts, and so forth, are supported by applications running on z/OS. Maintaining the applications that support these processes requires teams of skilled application developers. Finding and retaining good developers is a challenge for most organizations, and the relatively low salaries the University can pay adds to the difficulty. (Almost all staff salaries at the University are paid for out of funds allocated by the state legislature.) Since the early 1970’s, the University has responded by hiring people with little or no developer experience and training them in the skills necessary to serve. Of course, this cannot happen without other kinds of costs, and the University invests heavily in the candidates chosen for the training program. However, that investment has paid off significantly by producing a community of intelligent, skilled, and loyal employees. The training program has benefitted the University in ways beyond providing new developers. It teaches more than just technical skills; understanding and finding solutions to business problems, time management, and professional development are also emphasized. Several graduates of the training program have gone on to serve in management and executive positions at the University.

The University environment Universities first arose in the middle ages, and university governance still owes a lot to feudalism. The Colleges, Schools, and other Units (CSUs in current jargon) that make up the University have a lot of independence and discretion about how they acquire and use computing resources. (Note that the training program is focused on administrative computing applications. Research and instructional computing do not fall under its purview.) As a result, administrative application development at the University of Texas is highly federated, with many individual organizations employing their own development teams that work closely with their own staff and management—over sixty campus units employ members of our administrative development community. Working directly for the CSU helps developers to respond appropriately and quickly to the needs of their users and to align their applications more closely to business priorities. This decentralization does have the potential to create rivalries and

dissension, but the training program has helped create a community of developers that appreciate and support one another, and cooperate in making applications and the processes they support work together well.

Technical environment While applications running on z/OS form the core of the administrative computing environment, the University’s use of z/OS is fairly atypical. All mainframe applications are written in Software AG’s Natural programming language and store data in Adabas databases. (Adabas is also a Software AG product.) Most of these applications have web front ends. The web servers run on Linux and consist of scripts that interact with the Natural applications via Software AG’s EntireX Broker. These scripts were originally written in a home-grown CGI scripting language, but for the past six or seven years have been written in Python using the Django web application framework. The training program is designed to provide skills in using these technologies.

History of the training program Before the web In 1968 the University reorganized its Data Processing Division, which mostly served the accounting and student records departments. The new director of Data Processing, Robbie Simpson, came to the University from IBM where he had been the System Engineer for the UT account. (His brother, Tom Simpson, also worked for IBM and was one of the authors of HASP. This reorganization marks the beginning of our institutional memory of administrative computing at the University; very little is remembered of what happened before Robbie arrived.) Robbie Simpson continued as director of Data Processing through the early 1990’s, and the training program was instituted and developed under his management. In those days on-the-job training for programmers was common, since computer science was in its infancy and few formal programs for instructing programmers existed. Even after academic training became more widely available, though, Data Processing continued to hire inexperienced applicants and train them. At first this training was informal, but sometime between 1973 and 1975 the division formalized its training program. It was built around a series of programming assignments known as “challenges”. Completing each challenge required applying new programming principles, with the later challenges building on the techniques learned in the earlier ones. Originally, the assignments were completed by writing principally in COBOL, with some in Easytrieve. In the 1970’s the University began using a database named Total. However, when (around 1978) a proposal was made to computerize the library’s card catalog it required more advanced database technology, and Adabas from Software AG was selected in 1980. Along with Adabas came a new programming language, Natural, which made accessing Adabas particularly easy. Challenges were added to the training program to introduce this language, and the trainees who learned Natural began using it more and more. As Natural became more capable and more familiar to the developer community, the Data Processing leadership decided to stop development in COBOL and Easytrieve and focus exclusively on Natural; this decision was made in 1982. This of course meant changing the training program so that all the challenges were completed in Natural as well. This was the state of the training program when I was hired and went through it in 1987. While all administrative programmers were originally employed by Data Processing, in the early 1970s some developers began working directly for other departments. This process began slowly, but really accelerated beginning around 1990, when Data Processing gave control of

many of the central applications to outside departments and began focusing on infrastructure. Not coincidentally, another significant addition to developer training happened around that time. Administrative applications had been growing more ambitious and therefore more complicated, and as a result many developers were feeling that what they had learned during training was not enough to cope with these larger applications. Also, recent graduates of the training program did not have a clear path for career advancement, and could not move up until a more senior developer left or a department added a new position. To deal with these problems a new apprenticeship program was developed to provide post-training-program instruction, and approval was gained from human resources (in 1992) so that the new developers could be promoted once they finished their apprenticeship.

The web era A big change came with the World Wide Web. By the time it came along essentially all our users had computers with graphical user interfaces, and we had been investigating ways to provide better interfaces for our applications than 3270 emulators. We had been experimenting with Software AG’s EntireX Broker (as it is now known) messaging middleware, but hadn’t found a client-side development technology that would work with our diverse set of user platforms. In 1995 some of the analysts for the library asked us about putting a web front end on our card catalog application. When we looked into it, we realized that we could add a web server tier between our mainframe applications and the end user’s client machine, and let the browser developers deal with the variety of platforms in our user community. After evaluating the existing and (at that time) immature web development platforms, we decided to postpone selecting a long-term web development environment, and I wrote a simple Natural-like CGI scripting language for our immediate use. (We ended up naming it “webAgent”.) Of course, integrating these new technologies into our applications also meant adding them to the training program. Challenges and extra training modules were developed to teach HTML, CSS, webAgent, and related items. As it turned out, this era put a lot of stress on the training program. The “dot com” boom led to high market demand for developers who understood web technologies. The University was training new programmers in many of these technologies, so members of the developer community found a ready market for their skills. At the same time, like many organizations the University was devoting resources to making sure applications would survive the Y2K transition, so more new developers were needed than what had been normal previously. One result of this was that the training program became stricter and less flexible, to ensure that all graduates actually had the required skills. As mentioned above, the webAgent scripting language was intended as a temporary measure until we could select a mature web development framework. We had anticipated replacing it in four or five years, but it wasn’t until around fourteen years later, in 2009, that Python and the Django web framework were actually selected. (There were some efforts around

2000 to implement a Java web development environment, but they were unsuccessful.) This led to the most recent major change in the training program, when all the webAgent-based challenges were replaced with Python/Django based ones.

Going through the training program So how does the training program currently work? Let’s follow a trainee through the program and see.

Selecting candidates The education team maintains a “wait list” for units and teams that have or expect to have openings for software developers. Candidates are hired into the training program as needed to satisfy these positions. The University has an online job application site where people looking for work at the University may search and apply for jobs. Most candidates find the training program through this site or through word of mouth. In a few cases, CSUs (Colleges, Schools, and Units) that need programmers and have non-technical staff who have demonstrated interest and ability enroll these staff members in the program as sponsored trainees. Applicants preferably have at least a bachelor’s degree, but their major does not matter. (As you’d expect, applicants from STEM fields tend to do well, but we’ve also found that people with degrees in languages or music often become excellent analysts. You really can’t predict how well candidates will do based only on what they’ve studied in the past.) People who wish to apply for the program are informed of the next time a programmer aptitude test will be administered. This test serves as the first level for screening potential candidates. Those who score high enough on the test become eligible to apply for Software Developer Trainee positions posted within the following two years. Applicants that have passed the test and applied for a position are interviewed over the phone. If the candidate passes this interview he or she is invited to interview with a panel of developers, and then for one final interview with the education manager. (Cassidy Lamb is the University’s current ITS education manager.) The focus of these interviews is on communication skills, work ethics, aptitude, and attitude. The intent is to hire people who take responsibility for their mistakes, can work independently but also work well with others, are able to communicate effectively, and have the logical problem solving skills required for technical work. The University’s Human Resources policies state that during the first six months of employment an employee is considered on probation and may be let go at any time with minimal paperwork. Trainees are expected to complete the training program within this probational period. (A typical trainee finishes in about five months.) The selection process has been designed to find those most likely to successfully finish training, and between 85 and 90% of trainees do. Sometimes a trainee finds that he or she doesn’t really enjoy program development and drops out. Sometimes a promising candidate lacks the necessary work habits

and sense of responsibility and is let go for failing to make progress. However, the education team and developer community put a lot of resources into supporting trainees, and anyone who makes a sincere effort is likely to succeed.

Beginning training Once the new trainee has been hired, he or she will meet the education team and receive orientation. Each trainee is assigned an education coordinator to serve as his or her supervisor throughout training. The education coordinator monitors the trainee’s progress through the program and ensures that he or she is progressing at an appropriate rate. Education coordinators are either full-time members of the education team or developers from a CSU that needs new programmers. (If the trainee is being sponsored by a CSU, that CSU must provide the education coordinator.) An education coordinator spends about five hours a week supervising each assigned trainee. Each trainee is also assigned a mentor, typically a senior developer. The mentor meets briefly with the trainee on a weekly basis. Mentors provide encouragement and advice, tell stories, and otherwise help the trainee to feel a part of the UT developer community. If issues arise with the trainee’s performance, the mentor serves as an advocate for the trainee to ensure that he or she is being treated fairly.

The challenges The core of the training program consists of eleven challenges. Six of them focus on Natural programming on the mainframe, one covers web technologies like HTML and CSS, and four teach Python and the Django web application framework. During the challenges the trainee designs and codes a complete mock application known as “Staff Training Central”; this application could be used to manage courses and classes available to staff members. (It is modeled on a real application the University uses for this purpose.)

Typical home page of a trainee’s Staff Training Central web application.

For each challenge the trainee is given a business problem to solve, readings and other resources describing the technologies to use to solve the problem, a list of concepts they should learn during the challenge, and a set of deliverables the trainee must produce to prove completion of the challenge. One or two senior developers serve as lead analysts for each of the challenges and maintain this information and related resources. A current developer from the UT administrative community, known as a challenge analyst, supervises the trainee’s work for each challenge and provides project management and technical guidance. For one challenge, a challenge client is also assigned. This client is a developer or experienced end user who role plays as a business manager or user from whom the trainee must elicit requirements and priorities. A code review is required for most of the challenges. Two of them also have design reviews. These reviews are attended by the trainee and his or her education coordinator and mentor, by the challenge analyst and the lead challenge analyst, and by a senior analyst and a junior analyst. The education manager also attends when she is able to. Except for the trainee, the mentor, and the education coordinator and education manager, these are different people for each challenge the trainee completes. These reviews are not adversarial; the participants focus on helping the trainee understand good design and coding practices.

A trainee conducts a code review

Of course, the primary deliverable for each challenge is the code that solves the business problem. Many challenges require a testing checklist (developed by the trainee) to verify that all the business rules are satisfied by the code. At various points during the challenges, the trainee takes diagnostic tests or short classes on special topics. Some additional notes about the challenges: The challenges cover much more than technical skills. Trainees learn about understanding business cases, communicating with end users, project management, and other professional issues. Because of the different challenge analysts, the challenge client, code review attendees, and other interactions with members of the administrative development community, the trainee comes to know and be known across this community. Much of the training program is designed to give the trainee a sense of membership in the developer community. The administrative development community makes a heavy investment in the trainees. The education team estimates that challenge analysts, review participants, and challenge clients contribute approximately 160 hours to the education of each trainee.

Completing the program At regular points during the program the trainee undergoes a formal evaluation. The trainee meets with the education manager, his or her education coordinator, and his or her mentor. The trainee’s progress is reviewed, strengths and weaknesses are identified, and direction is given on how to address any issues that may be hindering progress. The results of this meeting are written up and provided to the units on the waiting list to assist in placing the trainee upon completion of the program. For the final stage of the training program, the trainee formally demonstrates the “Staff Training Central” application he or she has written. This demonstration takes about half an hour, and all the trainee’s challenge analysts, review participants, and others who helped are invited to attend. At the end of this demonstration the trainee’s mentor presents him or her with a certificate of completion, and traditionally a few small gifts to serve as mementos of the training experience.

A trainee demonstrates her “Staff Training Central” application to complete the training program.

Once finished with training, the new developer/analyst (no longer a trainee) joins his or her production development team. Those sponsored by a CSU go back to their sponsor, of course. Other trainees begin interviewing with teams on the waiting list a few months before completing training. The education team works with the developer teams and the trainee to make sure that the candidate is a good fit for the team he or she will be working on. Once a trainee has been placed, the CSU that selected him or her reimburses ITS for the salary paid the trainee during the training program. A CSU can get priority in selecting a candidate from the training program by paying this cost up front and providing an education coordinator.

Continuing education Although the training program prepares trainees to begin work on production projects, they still have much to learn. The developer community continues to provide supervision and opportunities even after graduation from the training program. The nature of these opportunities, and how much the developer will be able to take advantage of them, depends to some degree on the College, School, or Unit (CSU) where he or she is placed, but in most cases it includes the items mentioned here.

The apprentice program For roughly the first year after completing training, the new developer will be a part of the apprentice program. In almost all CSUs new developers must complete the apprentice program before becoming eligible for reclassification or promotion. An apprentice committee of senior developers supervises this program. The main elements of this program are interviews, classes, and reviews. An apprentice begins the program with an orientation meeting with a member of the apprentice committee shortly after completing training. He or she will also have two or three interviews led by a member of the committee. The first interview takes place approximately six months after completing training. During this interview the second interview is scheduled, usually about six months to a year afterwards. These two interviews are also attended by the apprentice’s supervisor (or supervisors.) In these interviews, the apprentice describes the projects he or she has been working on, the business goals of the unit, and what he or she has learned since completing training. The apprentice’s supervisor(s) provide feedback on how well he or she is progressing. If the apprentice has completed all other requirements and is making satisfactory progress, then the second interview completes the program, and the apprentice may be reclassified. If issues are identified during the interview, then the apprentice is directed to work on them and a third interview is scheduled in approximately three months. During the program each apprentice is expected to take and complete two formal classes, a short one on web application security and a longer, eight-week course on systems analysis. In this second course, members of the developer community teach sessions on programming languages, efficiency, Entity-Relationship diagrams, project management, designing use cases, assessing risks, and other technical and professional development topics. As a part of this course the apprentice also creates a portfolio of current work and gives a short presentation related to a current project. Another apprentice program requirement is to conduct a formal technical walkthru related to a major project. All developers are expected to conduct regular code and design reviews with members of their team and other collegues, but for this apprentice requirement the walkthru also includes a member of the apprentice committee, a member of the systems staff, and a

member of the information security office. Besides the regular issues covered in a design or code review, this walkthru should demonstrate the apprentice’s technical skills and understanding of business problems. The apprentice is also expected to contribute to the education of others, by serving as a challenge analyst, attending trainee reviews, teaching a class, developing educational materials, or in some other way. He or she must also demonstrate ability to communicate with business clients and end users, and make at least one formal presentation on a business or technical topic. There is also a semi-formal “peer group” of developers who have recently completed training. Membership in this group overlaps significantly with the group of developers in the apprenticeship program. This group meets regularly; some meetings involve presentations (by a member of the group or an invited senior analyst) while other meetings are purely social.

Other educational opportunities Even after completing an apprenticeship, developers at the University have opportunities for further education. Classes are occasionally taught on a variety of technical topics, and there is a group with regular monthly meetings to discuss Python development. Also, the community holds an FYI presentation every Wednesday morning covering a wide variety of topics. These range from technical topics on programming to announcements of new services to information on University programs like recreation and exercise services. Many CSUs support their developers continuing their education in other ways, including through informal research, formal third-party courses, or conferences (like SHARE!) They are encouraged to communicate what they’ve learned with the community by teaching classes, presenting an FYI, or in some other way.

Conclusion Over a period of over four decades, The University of Texas at Austin has been able to hire and retain successful developers through a training and continuing education program that takes in people with high aptitude and good attitudes but little or no computer experience and provides them with the skills to develop effective business applications. While this program has required a significant investment of University resources, it has paid off by creating a cohesive and supportive community and culture that has helped the University meet its administrative requirements. Perhaps this community and culture represent the most significant and lasting impact of the training program. Despite the fragmented nature of university governance and the natural competition between the various units they work for, developers and analysts at the University of Texas help and support each other in ways that allow its administration to work effectively to meet business needs.