Communications of the ACM
Reinforcing Computer Science Education
I am a career software engineer and I have had the opportunity over the past decade to engage with computer science students in a number of modes. I have performed a number of guest lectures as a supplement to formal classes, as well as technical talks to computer science student groups. I've served as a judge at hackathons. I've also supported technical recruiting, which is important as new talent is the lifeblood of any thriving organization. Across these interactions, there is a common theme to most student questions: what skills should students pursue? What do computer science students need to know to be successful in industry? These are important questions, and this is advice I typically give.
Standard Preamble
Formal computer science education is challenging as the number of technical topics and complexity of those topics keeps increasing, but the number of available credit hours in which to teach is constant. That is a tough problem, and I don't envy the job of professional educators. I leave the task of re-imagining or re-creating the core computer science curriculum to those professionals. This article is about *reinforcing* that curriculum—whatever it happens to be.
The first thing that I emphasize to students is that technology changes, so to get ready for a lifetime of learning. It sounds trite, but it's true. Pascal was the hot language for a time, then C, then C++, then Java, and at the time of writing Python has traction for multiple mainstream uses. But the fundamentals don't generally change, so students should ensure they understand both core concepts and implementations of those concepts across as much of the technology stack as is feasible to squeeze into a degree, from operating systems to networks to data stores to compilers to programming languages and data structures and software engineering and beyond.
Secondly, every industry has a distinct set of challenges. The factors that determine success in the financial sector aren't necessarily the same as healthcare, for example. Some of the differences are inherent in the domain itself (i.e., knowledge of accounting/finance vs. biology/anatomy/pharmacology, regulations), and some are technical challenges that are specific to the sector (e.g., trading platforms vs. EHRs). So when students ask about "succeeding in industry" the critical question is "which industry?" While computer science fundamentals are broadly applicable, that is just the beginning.
Core Reading
Over the years I've recommended three software engineering books to students, each covering a particular aspect of the art.
- Effective Java, Bloch —A great book written in the style of Effective C++ by Myers, covering both Java language gotchas they might not be aware of, as well as a gentle introduction to some key design patterns.
- Refactoring, Fowler—This book starts with the assumption that you've inherited a bunch of code and then have to recognize and remedy bad smells. While the code examples are in Java, the concept is foundational because this experience of inheriting code is practically a rite of passage.
- Design Patterns, Gamma et al.—While just about every CS student is familiar with some aspect of software design patterns, not nearly as many have read about design patterns in the "original Greek," so to speak. Code examples in C++. Read this last as it tends to make more sense the more code has under one's fingers.
While these two of these books are Java-focused and all the books object-oriented in nature, I still think those books do a great job of describing the difference between "programming" in general and "software engineering."
At the risk of violating my own assumption of not suggesting changes to the academic core, I would strongly advise computer science students to also get exposure to data science and artificial intelligence. The historical difference between traditional computer science programming and statistical programming used to be stark. Now AI, machine learning, and data science platforms are not only converging with many mainstream development platforms, but modern solutions are expected to incorporate elements of both instead of being delivered in siloes.
Student Groups
Student groups are an important aspect of computer science reinforcement. My favorite example is a group that I have had the pleasure of working with at Case Western Reserve University called the Hacker's Society, or HacSoc for short. It's a "Case study," pardon the pun.
The Case HacSoc started in 2007 as a collaborative backstop for computer science students, as some computer science students come in with more experience than others, and not about pranks or stunts as the name might imply. And while it did initially have an emphasis on computer security (e.g., how SQL injection works and how to protect applications from that attack vector), the HacSoc was primarily focused on educational self-defense: Linux command line essentials, how source control systems work, and later as the group grew on how to prepare for technical interviews. There wasn't an application process; one just showed up. "Anyone can do this! And that means you!" was the mindset. And in the early years it was not just student-organized, but it consisted of almost entirely of student presentations.
As the story was told to me, while the computer science department supported the HacSoc, the rest of the university did not greet the news of a "Hacker's Society" with uniform enthusiasm. Case is not only a research institution with undergraduates, masters and Ph.D. programs, but also has medical and law schools. There was reputational damage to consider beyond just the computer science department, and the notion of a sanctioned university group perceived to be engaged in what the general public understood as "computer hacking" appeared to some to be only slightly less outrageous than asking for a student charter of the Hell's Angels Motorcycle Club. The HacSoc tried to explain that "hacking" went back to MIT in the 1970's with exploration and HAKMEM-style knowledge sharing, and the term been corrupted into what had originally been understood as "cracking." In an attempt to avoid controversy, the university requested that the group change its name. The HacSoc, however, replied that as it had never actually applied to be a recognized organization, the university couldn't mandate that change, and politely refused. As official campus organizations were eligible for a modest amount of funding, this was more than a principled stand over a computing term. The HacSoc would not change its name for anything, pizza money be damned. Thus the HacSoc began a multi-year existence as a quasi-renegade entity. Not anarchic, just iconoclastic.
It was a couple of years after the formation of the group when I gave my first guest talk to the HacSoc and it was pointed out to me that they were still not an official organization on campus. I could see that this was a small but curious and intelligent group, and I can state from personal experience the group was not afraid to ask questions of guest speakers. Over following years, a few more things happened. The membership between the HacSoc and the ACM student group reached a tipping point to where both organizations were more or less the same thing. Not exactly, but enough. Big events such as hackathons were officially organized by the ACM, but also advertised under the HacSoc banner. Just as significantly, the HacSoc built a reputation for technical expertise, though not always for having highest GPAs, as side-projects sometimes got in the way of coursework. It also built a reputation for landing internships and interesting jobs. *That* got the university's attention. Now it didn't seem so crazy to have a "Hacker's Society" on campus. In defense of the university's initial reticence, the HacSoc proved itself to be true to the original hacker ethos with results.
So find a student group, or if all else fails, create one!
Hackathons
Hackathons are a frequent outgrowth of student groups, and the big events turn into all-weekend affairs with competitions and sponsorships. These are great opportunities for collaboration and bonding. I would caution student groups not to get too caught up in the competition aspect, however. I've seen a project or two that I'm pretty sure had been worked or planned a few weeks in advance, and while those projects were impressive, but that's not really the point of a hackathon. I would suggest competitions consider categories such as Most Audacious Fail to reward the original spirit of "did it in a weekend" exploration and hacking.
Open Source Software
Open source projects are a great opportunity to see software development in action. Open source software is more than the code itself, it requires a community around the code to be successful. And as open source projects are created maintained by humans, they tend to have human-style strengths, weaknesses, idiosyncrasies, and drama, and consequently make fascinating observational laboratories.
When selecting an open source project to follow, pick something of personal interest. There are always "hot" projects at any point in time, but the most appropriate project should be something that you want to spend a lot of time on and, ideally, use. Sometimes the technical complexity of projects can be overwhelming, so be patient and take things one day at a time. Also, per the previous comment about human strengths and weaknesses, not all projects are equally welcoming and supportive of new members. Use your own judgement for fit.
For those not familiar with open source, I would suggest the following steps for involvement:
- Check out the code
- Read the documentation
- Get the code running locally (or somewhere)
- Sign up for the dist-lists
- Check out the issues or tickets (e.g., Jira)
- Understand the project's open source license
- Contribute!
Just going through steps 1-6 can be a tremendous learning experience, in terms of how to organize sizable codebases, understand how well documented the projects mission is (and whether it is actually following its documented mission), and how the community behaves and organizes itself. Just being open source does not guarantee success as the Apache Attic, for example, is filled with dead projects. Understanding the particulars of open source licensing is beyond the scope of this article, but suffice to say it is a complex topic and should be added to the list of things to research and understand.
There are multiple levels of contribution as well. Many people new to open source development assume that contributing only means coding of new features, but this is not correct – it takes a lot of people to make a successful open source project. Contributions could come in multiple forms:
- Answering people's questions on dist-lists.
- a. Pro-tip: be sure to read the documentation carefully before posting questions, and look at prior posts to see if a question has been asked before. You will make friends much faster this way.
- Logging bugs when they are found.
- Logging suggestions (especially of the 'getting started' variety).
- Improving unit tests (either creating or improving).
- Improving documentation.
- Performance testing.
- Improving the build process.
- Bug fixes.
- Feature improvements
My own experiences in the early years of the Apache HBase project included improving documentation and co-authoring the HBase Reference Guide, as well as engaging in a lot of question answering on the dist-lists. I had more than a full-time job in a startup, and HBase was my nights and weekend work. The documentation efforts aligned with my interest, needs, skillset, and just as importantly my schedule. In a successful open source project, there is always more work to be done, and every little bit helps!
Good luck, and happy hacking!
Author's Note
Special thanks to Tim Henderson and Stephanie Hippo for history on the Case Western Reserve University Hacker's Society.
References
HAKMEM – the "hacker's memo" from MIT from the 1970's. https://en.wikipedia.org/wiki/HAKMEM
Apache Software Foundation – open source "The Apache Way" https://www.apache.org/theapacheway/
Apache Attic – dead project list https://attic.apache.org/
See Also
Hacker's Delight: a great book on bitwise operations, in the original understanding of "hacker." I would expect this book is often confused with books on network security. https://en.wikipedia.org/wiki/Hacker%27s_Delight
I wrote a personal blog in 2018 on how to become involved with open source software: https://themeildeal.blogspot.com/2018/11/how-to-get-involved-with-open-source.html
Doug Meil is a portfolio architect at Ontada. He also founded the Cleveland Big Data Meetup in 2010. More of Doug's ACM articles can be found at https://www.linkedin.com/pulse/publications-doug-meil
No entries found