Programmers, Let’s Earn the Right to Be Called Engineers
As a structural engineer by training and a web developer by vocation, I find myself on both sides of the argument Ian Bogost makes in his Atlantic piece, “Programmers: Stop Calling Yourselves Engineers.” I know what it means to consider engineering a calling. After all, I studied seismic structural engineering and once designed buildings for life safety. I remember the hours spent studying for the National Engineer in Training and Professional Engineer exams. I recall the pride I felt receiving my official stamp, emblazoned with my name and imbued with heavy civic responsibility.
These days, though, I’m not poring over technical details, blueprints, and elevations. I’m not patrolling construction sites, checking the distance between column rebar ties and reviewing concrete core samples. Many years ago, driven by my budding interest in computer analysis of structures, I pursued programming. Today, I am WIRED’s director of engineering.
I’m still solving problems, still designing and building things. And here’s what’s surprising. My husband is a structural engineer (yes, we met at work, my first job out of grad school). When we talk about work at dinner, I see striking similarities in our days. He builds the structures envisioned by architects; I build the systems envisioned by art directors and editors. We both appreciate aesthetics, but fight for performance and security. And we both manage projects, people, and clients. But if he makes a mistake, people may lose their lives. If I make a mistake, my employer may lose money.
That’s not to say I take my job any less seriously than my husband does. But the accountability just isn’t the same, nor are the professional standards. Which makes me wonder what it would take for software engineers to earn the title “engineer” the way civil, mechanical, aerospace and other engineers do. In other words, what makes an engineer an engineer?
Engineers Design/Build Things and Solve Problems
This is by far the greatest overlap between people who build with code and people who build with steel and concrete. Software developers must solve complex problems; envision unintended use cases; and ensure the capacity of their designs, just like bridge builders. Their designs evolve over time, innovative frameworks arise, standards improve. As a structural engineer, my colleagues and I served on committees to improve and refine building code standards. We used seismic events to learn more failure patterns and prevention techniques. As a software developer, my colleagues and I constantly adopt new process tools (think Node, Docker, Jenkins, Vagrant), invent frameworks, and strive to improve performance (think decreased start render, server load). And we learn from failure, applying those lessons to future projects.
Engineers Are Always Learning
Most of the structural engineers I know are always learning. They attend monthly engineering association meetings, where colleagues discuss and dissect recent projects. They attend two or three conferences each year. They serve on code committees. Software engineers are no different. We spend a large amount of time pursuing similar activities in addition to attending meetups, workshops, and hackathons. Coworkers often cite this continuing education and endless pursuit of innovation as a big reason they love their jobs.
Engineers Feel a Sense of Calling
While licensed engineers often feel compelled to change the world through infrastructure and invention, software programmers typically get passionate about innovation and automation. Both disciplines provide a deep sense of satisfaction and fulfillment in creating something, be it a skyscraper, a robot, or a website. We start with a blank page and fill it with calculations, code, or drafting details. We help break new ground, literally and figuratively. We freely share our experience and know-how with others. Why would software engineers share code through open source, if not out of a sense of duty, a desire to give something back? Boeing wouldn’t share the engineering drawings of its 787 Dreamliner the way Google is sharing TensorFlow.
Engineers Are Accountable
For all the similarities between software developers and what Bogost might call “real” engineers, there is one significant difference: accountability. Engineers must answer for their work legally and professionally. They are bound by honor and state regulatory boards to produce work that is correct, safe, and up to the best practices. Engineers can lose their licenses through negligence. For example, the structural engineer of record places his or her official stamp on all drawings and knows that if the building should collapse, he or she will be held to account.
Software development doesn’t have such rigorous accountability, and this may be the area where we stand to improve most. For us, accountability tends to mean a midnight call—you break it, you fix it! What if every piece of code we wrote linked publicly to our GitHub accounts? What if we, like licensed engineers, had to sit for exams before reaching the next level in our careers, as I had to do before being promoted from structural designer to design engineer? What if we, as managers, had to read all 335 pages of The Guide to the Software Engineering Body of Knowledge and understand everything it represents?
I will not claim there aren’t software programmers who don’t uphold best practices, who are sloppy with code, who “move fast and break things” in a way licensed engineers never would. But we as an industry are doing a far better job than ever of abiding by code standards and running our work through linters and validators. There plenty of full stack engineers who pursue excellence, who follow rigorous processes, who would happily support a licensure exam. In fact, two-thirds of programmers support such a test, according to the National Council of Examiners for Engineering and Surveying.
If we as a community can apply our ability to learn on the fly and our problem-solving skills to finding ways of holding ourselves to a higher degree of purpose and accountability, I have no doubt we will prove software engineers are “real” engineers.
See the original article here: