Three things I learned as an intern at Chicago Public Schools
This summer, in addition to working on revamping YSFlight Headquarters and taking Startup Engineering via Coursera, I took on the challenge of interning at the Information & Technology Services (ITS) department within Chicago Public Schools (CPS). Having taken an Oracle Database Design class and participated in CPS’s Career and Technical Education program, I was offered a chance to work with the CPS Oracle team. As I have always wondered what technology powered the third-largest school district in the country, I jumped on the opportunity.
The first day of the internship was a warm and sunny July day. Sitting in the air-conditioned CPS Central Office in downtown Chicago, the team of interns listened to various presentations on the organizational structure of CPS, the roles of different teams in ITS, and eventually got a tour of the building. At the end of the day, we were given team assignments - these would be the group of people we would work with throughout the 6 weeks of the internship. By sheer coincidence, I was assigned to the Web Services team at ITS, which manages the CPS.edu website. The Web Services team also coordinates with various other departments to deliver effective websites and web applications. Having developed many websites myself (my first was when I was 11 or 12) the team was a good fit.
The second day was my first day on the Web Services team, so that also involved a bit of time to get acquainted with members of the team. This brings me to the first thing I learned…
Effective communication is just as important, if not more important, than writing effective code. Often, the image someone has of a programmer is a person that sits in a dark room alone and types away on their screen. They only communicate with others through instant messaging or email, and almost never see the light of day. However, this perception is completely false. While some programmers may choose to seclude themselves away from human contact, software engineering is a field that demands strong communication skills. The best engineers work in teams, and they need to be able to talk about their progress so that everyone on the team can understand. CPS was a good example of this in practice.
On that second day of the internship, I was given my assignment by one of the web producers on the team. The way the assignment was explained was very business-like, talking about existing problems and “objectives” that needed to be accomplish, as well as our mission of addressing the “customer’s” needs. My assignment was to find a way to direct schools toward design best-practices for their website, so horrendous site designs could be avoided. However, also allow schools to have a few degrees of freedom to customize their design as they wish.
At first, I was unsure of how to go about accomplishing the task, for it seemed vague and open-ended. Previous projects I had worked on had very defined objectives, and solved a specific problem. This was one of the first times I was able to exercise my own judgment in how to go about solving the problem. My first instinct was to start brainstorming and experiment with different ideas to see how they would turn out. I was able to hack the HTML and CSS that the tempting engine in the CMS used, and with the help of some JavaScript, create a plugin that would add a background image to the CSS (the background image being defined on a configuration page).
At the next team meeting, I showed off my work. The team was impressed by the “hack” but noted that it still didn’t solve the problem, which I acknowledged. We then took a moment to discuss what we could do to address the problem. The other intern on the Web Services team, Sufyan, came up with the great idea of creating a template that schools can use to help build well-designed websites. The template would include all the design basics as well as some color choices, so the risk of any horrid color combinations was lowered dramatically. With that idea solidified, we got to work.
While in the process of building this new template, I learned something else, particularly about the companies that I want to work at…
The enemy of innovation, especially in software development, is bureaucracy. While I personally did not feel the effects of being at a monolithic organization as much as others, I did notice it in some of the projects my coworkers (as well as other interns) were working on. As many Chicago residents may know, Chicago Public Schools is a troubled organization. It has faced years of underperformance, huge budget shortfalls, and general neglect. A byproduct of this (or perhaps a cause) is the slow-turning gears of bureaucracy and long delays before a project can be carried out.
My exposure to this comes from another project I was working on, a content audit of CPS.edu. With three others, we had to go through approximately 3,000 URL’s, many of them webpages or PDF documents, and decide if they should be archived or not. While performing this arduous task, I was able to get a look at the vast scope of the organization. It occurred to me that many great ideas can take years to implement (if the idea is lucky enough to go that far) because of so many approvals that are needed by various department heads along the way. Furthermore, at one of the team meetings, a coworker noted that often times they were the ones waiting for a response from the customer (another department at CPS) versus being able to quickly execute and deliver the best solution.
As I have learned, your ability to communicate with clients is the difference between a brilliant success and an awful failure. This brings me to the final thing I have learned while at CPS…
Document your product for the “lowest-common-denominator” user. No offense to my users, but some of them can be absolutely clueless when it comes to using software. Additionally, some users may not be native English speakers (or English speakers at all) so it’s important that developers also document their product for a wide audience (if they intend to reach the largest market). Being able to write great software is only half of the story - if nobody knows how to use the wonderful features of the software, then is it really great? Like in my first point, effective communication is very important to convey ideas, thoughts, and directions.
Once I had the template built and tested, it was time to create documentation for it. We (Sufyan and I) went about documenting the process to use it. I created a PDF manual with a step-by-step guide, and he created a series of video tutorials for more complex steps in the manual. I discovered that there is a fine line between simplicity in explanations and the need to cover all the intricacies of the software & OS. Luckily, with all the screencasting software available, it is now possible to record every motion and play it back on command. This makes creating interactive tutorials much easier, and allows for more information.
While creating the initial template manual and videos, it became important to continuously test our own content for clarity. As we could not get some test users for most principals and teachers were either on vacation or preparing for classes, we just “played dumb” and worked through our own tutorial. On the last few days, we wrapped up by doing final tests on our template, documenting code, and proofreading the manual one last time.
To summarize:
- Effective communication is key to any software development career
- Bureaucracy is the enemy of innovation (and you should avoid it)
- Document your product for your most unskilled user
Overall, I found the internship to be a worthwhile experience. While I disliked the working environment (cubicles and dim fluorescent lights do not sit well with me), I gained some new insight into my career path.
What I created while at CPS: http://schoolsite.cps.edu/template.html
The template in action: http://sampleschool-cps.weebly.com/
If you would like to talk with me in greater depth about my experiences, shoot me an email at [email protected]. I’d love to chat sometime.
If you enjoyed this post, I’d be humbled if you would follow me on Twitter.
Thanks to Safia Abdalla and Patrick Andrade for reading drafts of this.