Software Developers Are People

As software developersIn this essay, the term “software development” encompasses all roles and disciplines that contribute to the study and creation of computer programs and systems. We treat “programming” and “software development” as synonyms and use them both throughout this essay.

, we each hold unique views of what creating software entails and how to best approach software design and programming. Maintaining an online transaction processing system running on an IBM mainframe is different from building the front-end of a web application; writing a Linux device driver is different from wrangling a dataset to create a visualization; designing flight control software for a modern airliner is different from scripting a non-player character for a video game. These scenarios differ in more than their application domains: The people working on these projects build software with different programming languages and different tools. They use different development processes, adhere to different programming paradigms, and speak with different jargon. Further, someone doing these activities professionally will encounter different wage scales and follow different career paths. Software developers operate within complex environments constituted of cultures (Petricek, n.d.)—people and practices—and tools. To understand software development, and who we are as software developers, we need to understand how people work within their environments. This essay explores the concept of a software umwelt—and how it is formed, shaped and tuned over time—as a way for software developers to understand themselves and to navigate the complex and ever-changing environments in which they work.

The concept of umwelt was first formulated by the German zoologist, Jakob von Uexküll, who proposed that humans, as do all living beings, experience life in terms of species-specific, spatio-temporal, “self-in-world” subjective reference frames (Ostachuk 2019). In German, umwelt means “environment” or “surroundings.” According to von Uexküll, there are two aspects to our umwelt: (1) our unique perception of the world and (2) the actions we can take to affect that world. Our umwelts are personal and unique. What we see is not necessarily what we perceive: How we act on our perceptions is partly based on the significance we assign to them. For example, many primates, such as chimpanzees, will recognize a rope lying on the ground that is attached to visible but inaccessible food. They will pull the rope to retrieve the food. In contrast, tree-dwelling gibbons, when on the ground, ignore such a rope; but if that same rope is hanging from the top of their cage, gibbons will pull it to get the food (Bridle 2022). Apparently, a gibbon’s umwelt has an arboreal focus that filters out a rope on the ground. Gibbons are biological creatures, so are people—including programmers.

Our umwelts are multi-faceted. People operate in many contexts, such as home life, work life, and public life, where we perceive and act upon different things. For each of these contexts, we have our own specialized sub-umwelt. Software development, whether it happens in professional settings, classrooms, open-source projects, or elsewhere, is one of these contexts. Thus, every software developer has a unique software umwelt which is part of their more general umwelt. In this essay, we explore the ways we might examine the proverbial ropes in our software umwelts, the ones we recognize as well as the ones in our blind spots, in order to be better software developers.

To Develop Software Is to Adapt

Our programming habits, as well as our software design values, heuristics, and practices seep into our umwelts through our experiences (Wirfs-Brock 2023). Within the broader discipline of software development, we form communities based upon beliefs and practices—communities that sometimes have major conflicts about what is a more intuitive or appropriate way to work. Controversies sometimes divide the worlds of software development: Some things that a programmer of a dynamic object-oriented language considers to be best practices would be considered undisciplined or even dangerous by a programmer from the purely functional programming world. Why is this? How is it that we come to develop such strong feelings about core beliefs and values that drive our software practices? And are there ways for us to reshape our beliefs if they have become counter-productive? We assert that noticing and describing our own software umwelts can help us more deeply understand our relationship to these different software communities and might give clues as to how we might navigate between them.

From the transition from mainframe computers to personal computers, to the internet, and now to the use of large language models as generative tools to write code, software development has always been about change—in our tooling, our programming languages, our deployment platforms and design processes. When we encounter something unfamiliar in our environment or enter a new environment, our umwelt can no longer be a reliable guide. It may even mislead us. In such situations, only our untuned perceptive capabilities are available to us. We don’t know what’s significant nor are we adept at determining appropriate actions to take.

While our umwelt dictates our perceptions and constrains our actions, it isn’t static. Through interactions with our environment, we learn and adapt, and as we do, our umwelts grow and evolve with us. The concept of umwelt may be a useful model to help programmers navigate inevitable change—but only if we can be aware of our umwelts first.

How Do You Spot a Software Umwelt?

The trouble with umwelts is that it is hard for us to perceive them: How do we go about seeing our own eyes, or smelling our own noses? If everything we do is filtered through our umwelt, then we can never truly step outside of it. So is the task of trying to sense our own umwelt a futile exercise? Maybe, but in this essay we are going to try. Just as pair programming helps us understand our own coding habits and thought processes, we posit that our umwelts might become evident when they bump up against those of other software developers.

To explore this idea, we the authors embarked on a collaborative journey to understand our own, and each other’s, umwelts. We are closely related: Rebecca and Allen are married, Jordan is their daughter. We have had many discussions about software design and programming—over beer, over the phone, in the car, in our easy chairs—where we told stories about how we got involved with programming, how we think about it, and what we love about it and what irks us. We were intrigued by our differences, and our discussions were interesting (to us), but unfocused. So we decided to use the concept of umwelt as a lens to observe and reflect on our prismatic approaches to software development, by noticing and describing how our respective experiences have shaped our umwelts.

We tried an experiment: We would each write a reflective narrative discussing the emergence and evolution of our unique software umwelts. Because of umwelt theory’s emphasis on individuals’ unique perceptions and resulting actions, we can compare the effects of our experiences on our different umwelts. To begin this process, each of us independently wrote a narrative description of our own software umwelt by responding to a prompt that includes these questions: How do you perceive software development? What values do you assign to those perceptions? How do you approach a programming problem? How did you learn to develop software the way you do? Why do you act the way you do and not in other ways?

We refer to these narratives as our software umwelt stories—and we will excerpt them throughout this essay to illustrate our ideas. These stories were just the starting point. Next, we read each others’ stories and commented on them, asking questions in places (“Does the distinction between between applications programming and systems programming still exist as such?”) and reacting with surprise in others (“So interesting that you had to ‘translate’ Smalltalk concepts to other languages to conceptualize them! Can you expand on this?”). It is through this living discourse that each of our own software umwelts—and the nuances that make them unique—emerged.

Our process draws on philosopher Donald Shön’s idea of reflection-in-action. Shön observed that, “knowing is ordinarily tacit, implicit in our patterns of action and in our feel for the stuff with which we are dealing…our knowing is in our action” (Shön 1983). He suggests that we might tap into that tacit knowledge by engaging in surprise—by making familiar actions strange again so that we might re-examine them with fresh eyes. By telling our software umwelt stories—which included important events, origin stories, and other moments that stood out to us (e.g. caused us to be surprised)—we gained insights into how our experiences shaped our umwelts. By reading and asking questions about each others’ stories, we came to deeper insights. What seemed banal to a narrative’s author proved to be an interesting or surprising aspect of our umwelt formation by another.

Through this discourse we identified elements of a software umwelt story that seem most foundational, and turned those elements into threads. What follows are the threads that we found in our software umwelt stories. (Our full individual narratives and the common prompt we each started from are included as appendices to this essay.) With each thread, we’ve included a new prompt that we think will be useful to readers who want to repeat this exercise with their own software development team or class.

Umwelt Origin Stories

Prompt: What is your earliest memory of writing code? What type of device did you use? What activities did you do? Who else was involved in this memory?

Today, computing devices are ubiquitous and most children unconsciously incorporate the existence of such devices into their general umwelt. But there is a difference between using these devices and trying to manipulate them to create something new. We think that how and when someone first becomes interested in using computing technologies as a creative tool influences how they relate to those devices later on in life. Thus, reflecting on how we came to first understand programming can be a crucial foundation for understanding the rest of our software umwelt.

As we wrote our own software umwelt stories, we reflected on the origins of our relationships with computers and programming as an activity. Allen learned machine language programming in the 1960s at a summer course between the 8th and 9th grades on a Burroughs 205, a mid-1950s room-sized vacuum-tube decimal computer whose main memory was a magnetic drum. He found coding to be radically different than other educational experiences:

Allen: …I had many of the available science toys—chemistry sets, electronics kits, etc. but I had found them frustrating. They mostly provided recipes for experiments using the provided components. But, they didn’t teach me how to come up with recipes for my own science experiments. Programming satisfied that itch. Software was to be my creative media.

Rebecca didn’t lock on to a lifelong interest so quickly. When she encountered computing as part of a college job, she became curious about how computers worked and signed up for a FORTRAN programming class.

By the early 1990s, as Jordan was growing up, computer-based devices were more common and computing enrichment programs were available for children. Living with parents whose professional lives revolved around computing, they gave her small design problems to work out using CRC (Class-Responsibility-Collaborator) cards. Her parents told her this story many times, until it became part of family lore:

Jordan: …I imagine that I drew simple pictures to go along with the names of the classes and their responsibilities, and that I would discuss the solutions with my parents, who would weave in software design nuances so subtly that I didn’t notice…I also remember creating interactive stories using Hypercard in a summer camp…But as I got older, I left programming behind and focused on other interests: hiking, geology, creative writing.

We each have distinct software origin stories: Allen is the precocious adolescent discovering and compulsively pursuing a compelling interest. Rebecca is the curious college student learning that programming can satisfy an itch to understand more about what computers can do for us. Jordan is the computer-literate millennial initially trying to find a path distinct from her parents before (as we will see) eventually meandering back to software development. These software developer origin stories have implications that ripple through our umwelt development. As we grew beyond these early beginnings, we carried their traces forward with us.

Nurturing Our Umwelt

Prompt: How did you learn more about programming? What did you learn about yourself in the process? What were the “sticky” things you learned and why?

After being introduced to a new environment—in this case programming—our umwelt grows as we encounter more features and develop more perceptions and skills related to that environment. New skills may come from formal training, self-directed study, reference materials, other people, or hands-on experience. The skills and the style of their acquisition impacts our values and our beliefs about ourselves as programmers.

Since her first programming class piqued her interest, Rebecca continued to take programming classes (along with some computational theory) and ended up graduating with a double major in computer science and cognitive psychology.

Rebecca: I found I liked writing code because the amount of effort that I put in paid off in direct results. Also, I could work on my programs as much as I wanted until I got the structure and algorithms “right.” I liked tweaking code…

She found programming to be much more personally satisfying, and less stressful, than, “proving theorems in Calculus, where I had to get the ‘right answer’ at first crack.” In her practicum course, she wrote a small business application in COBOL for the computer center. Wow! With a little effort you could write programs that people actually use.

Allen credits the summer course using the Burroughs 205 for teaching him fundamental concepts of programming:

Allen: All computers can do is carry out commands to store, retrieve, and simply manipulate numbers. Any information—including a computer’s commands—can be encoded as grouping of numbers. Programming is all about identifying the informational part of a problem, choosing an encoding, and writing sequences of commands that manipulate the encoded information; most programs involve loops. You will spend a lot of time debugging your programs.

I still apply these concepts—in more sophisticated forms—when I program. They became fundamental tenets of my software development umwelt.

After that first course Allen, as a high school student in 1966, didn’t have access to physical computers; but that didn’t stop him from continuing to learn programming. He found books on programming at the public library and he discovered that,

Allen: [I] could walk into the local IBM field office and order complete manual sets for any IBM computer...I spent the next couple years reading manuals and writing programs on paper for desk execution. I learned that programming was an intellectual activity that I could do anywhere—even if I didn’t have access to a physical computer.

In contrast, Jordan wanted to put “intellectual distance between myself and and my parents” and didn’t further engage with programming until it was required by her undergraduate major:

Jordan: [I] bemoaned the required programming classes I had to take in my aerospace engineering degree—until I realized that I enjoyed them vastly more than studying fluids and thermodynamics. Still, computer programming felt cryptic, something that strayed just beyond the edge of my comprehension. I could scrape together passing assignments with a bunch of help, but they never truly made sense. It wasn’t until several years later, after countless self-paced courses, guided workshops, and half-baked personal projects, that things finally clicked.

What makes computing a “sticky” interest that leads us to develop a distinctive software umwelt? Perhaps this is a matter of self-perception, positive experience, supportive environment, and ongoing interest. Many kids go to computer camp or take intro programming classes and don’t transform into programmers, even casual ones. Some people learn a first programming language and stop there. The environment in which our software umwelt grows and develops is somewhat a matter of chance, but it is crucial to how we relate to software as a discipline: Is it supportive or competitive? Off-putting or welcoming? Engaging or boring? Is it fun?

Our beliefs about who we are and what we are capable of doing are key factors in how persistent we are at engaging with software development. By coming to understand what nurtures us, we can prepare for our unique software development journey. Not everyone is the same. Are you someone who learns best by interacting with others? If so, are you around the right people? Are you moetivated by self-learning? Are you determined to figure things out on your own? If so, are you encouraged to tinker and experiment? These characteristics and the situations you find yourself in can pull you in or repel you from software as a lifelong interest.

Putting Our Umwelt to Work

Prompt: When did you first feel competent/confident in your programming skills? What things did the “real world” teach you that you hadn’t studied? What was the first software project you worked on that made you feel proud, and how did it unfold?

Our umwelt moderates our perceptions and influences our actions. In some situations, our umwelt development may be driven by our need to take action in a new environment. Alternatively, our umwelt may be developed through training in preparation for dealing with an anticipated environment. As described up to this point, our software development umwelts were mostly developed through training. Ultimately, we each needed to face the real world of software development.

While in high school Allen found various ways to work with real world computers. He got access to programming environments on various timesharing systems and had free-range access to a PDP-8 minicomputer at the local science museum.

Allen: After high school I found a variety of programming jobs and eventually was credential motivated to get a CS degree …At that time a common division of programming labor was between applications programming and systems programming. I soon realized that I was a systems programmer—someone that builds “pieces of infrastructure that integrate multiple interacting parts, and sit underneath application code” (Kell 2017).

Allen spent nearly fifteen years at Tektronix as a Software Engineer ultimately specializing in programming language design, implementation, and tooling.

Rebecca, armed with a newly minted CS degree, landed her first programming job as an Analyst Programmer II for the city of Vancouver, Washington. But she quickly moved on to something more challenging.

Rebecca: I spent 3 short months writing thousands of lines of water and sewage billing code in COBOL…No one read or tested my programs—I was given hand written specifications which I took as a starting point. I penciled in my programs on IBM COBOL coding forms and gave them to our keypunch operator to type up.

Rebecca was comfortable in this software environment, as her COBOL programming skills she had acquired in school transferred directly. But no one cared about her code: They didn’t even read it. She thought that if this was all there was to was the life of a COBOL programmer, there wasn’t much more to learn. Rebecca didn’t want to program in a vacuum: She wanted to work with people who programmed as a team. She wanted to grow her programming skills and liked learning new things, so she sought more challenges. After a few months writing COBOL Rebecca was recruited for a Software Evaluation Engineer job at Tektronix and jumped at the opportunity. She tested graphics libraries, terminals, and an early graphics workstation. A year later she became a full-fledged Software Engineer I and was assigned to single-handedly build a linking loader that supported multiple microprocessor architectures. She was routinely assigned to design and build things that were completely new to her.

Rebecca: Over the next few years at Tektronix, I held engineering positions with increasing responsibility. I was lead developer for a networked file server…I led a fast-track firmware development effort for a low-cost graphics terminal. We wrote functional specs and created structured design documents. We incrementally developed and tested our code, and held frequent code reviews. This all was just standard practice.

In a rapidly growing tech company, with lots of new products being developed, there are plenty of opportunities to grow a software development umwelt. Through her experiences, Rebecca learned the discipline of an engineering process. She learned how to invent. And imprinted into her umwelt was the belief that she was capable of developing new and innovative software in areas where she had no prior expertise.

After several years without software development in her life, Jordan discovered the need to reactivate her vestigial software development umwelt. She earned a master’s degree in data-focused journalism and began working as a data curator in the non-profit sector. Here, she ended up as product manager for a complex software development project—a role in which she felt out of her depth.

Jordan: Thankfully, the lead software engineer I worked with was one of the most patient, generous people I have ever met. As he taught me what an agile development process was and how to run one, he was never condescending.

Within this software team, Jordan felt safe enough to learn and grow—which is not the case in all teams. This experience helped her see herself as someone who is capable of creating software: On this project, “I didn’t write a single line of code, yet I felt like I understood the software thoroughly.” After that project, Jordan worked as a data journalist for a public media news organization. Armed with the knowledge that she could comprehend code other people had written, she was excited to expand her programming skills on her own to do data analysis and visualization—something she may not have had the confidence to do without her prior experience of leading a complex software project.

Early in our careers, our umwelt may be less developed and readily adaptable to a variety of software development cultures. Unless we land in a newly formed organization or a fledgling project, we’ll have to fit into a pre-existing software development culture. Our umwelt will eventually need to conform, adapt, or reject that culture. As our umwelt further develops, our cultural fit will become a bigger factor in our future career choices.

We might land a programming gig, writing small, standalone programs. We might drift into significant programming activities as a vital side-effort in support of our “real” job. We might develop business applications or find ourselves immersed into an engineering culture where we are expected to learn new skills while designing and building complex software products and systems. But where we find our initial niche is largely a matter of the interests we decide to pursue (and whether our skills match that particular environment), and happenstance. But if you have an awareness of your developing software umwelt and your values, your next actions might be more purposeful.

Refining Our Umwelt Through Practice

Prompt: Describe how your relationship to software changed as your expertise grew. Did you become a generalist or specialist? How did your software development values and practices change?

If you work in a relatively stable environment, you may find yourself settling into a development rhythm. Your software development umwelt grows and deepens as you gain proficiency. As you take on new software development efforts, you will stretch your umwelt to acquire new knowledge and skills. You may encounter new-to-you programming languages and development tools. You may develop your own sense of style.

Allen found that he liked systems with “intuitive understandable command names and contextual defaults”—a preference that predates the development of GUIs. He disliked systems that used obscure notations or required the user to repetitively tell the system things it should already know.

Allen: This developed into a personal design aesthetic that was incorporated into my umwelt: Software is created by humans and exists to support humans and human activities. The design and implementation of software should be approachable, understandable, consistent, and comfortable to the humans that will interact with it. This aesthetic relates to both the internal design of software and to the design of software interfaces, both human interfaces and the interfaces between software components.

When Allen and Rebecca joined Tektronix, its corporate motto was “Committed to Technical Excellence.”A few years later, the motto was changed to “Committed to Excellence.” Some employees from that era believe this was the start of Tek’s decline.

The manifestation of that model in the Tek engineering community made a strong impression on both of them.

Rebecca: Tektronix was an engineering company where the “next bench” philosophy was practiced—build something of high quality that your peers would use.

Tektronix had lots of internal processes for designing and engineering hardware products…
most of the processes and various design documentation requirements we used were imposed on us software developers with very little adaptation.

My software development umwelt after 5 years at Tektronix as a Software Engineer was largely shaped by my experiences working with highly motivated peers who held themselves to high standards. We worked hard, we were supported by our management, and were expected to specify, design, and build products (and the software embedded in them) from the ground up.

Rebecca internalized the values that were formative to Tektronix’s engineering culture and grounded their practices. She came to deeply value producing quality software.

At the non-profit, Jordan “successfully” delivered a complex software project, a community data storytelling platform, on time and on budget. But she learned a hard lesson:

Jordan: …we delivered what we said we would deliver. At launch, our platform was beautiful, easy to use, and well-built. But…we delivered something that people didn’t actually want…We should have paused to do more exploratory research on the needs of our community members and stakeholders…but at the time I didn’t know to ask for it.

A couple years later, while working as a data journalist, Jordan, who had first programmed using Hypercard, discovered that a live programming environment was the key to her embracing coding.

Jordan: …I began dabbling with Python Jupyter Notebooks. For the first time in my life, I loved writing code. I loved being able to tweak a single line of code and see the results immediately in a data frame or data visualization. I felt like I had agency and power, and I understood what I was doing. Yes, I still faced extreme frustration, but it felt worth it because I could see what I was working toward.

Experiences can lead to discovering both what we like—which isn’t necessarily the same as what we are good at—and forming lasting interests. Our experiences not only contribute to growing our software umwelt, they also shape our beliefs about ourselves as people and programmers. If our experiences are positive, we are likely to seamlessly integrate many of the values, practices and perceptions of the programminmg cultures we are part of into our own umwelt.

Umwelt Pivots

Prompt: Describe a significant life or career pivot. Why did you make it? How did this change your views on software?

The term “half-life of knowledge,” coined by economist Fritz Machlup (Machlup 1962) denotes the time it takes for half of the knowledge in a profession to be superseded. To stay current in any field, we must acquire new knowledge and integrate it into our umwelt. In 2008, Philippe Kruchten took a stab at estimating the half-life of software engineering (Kruchten 2008). He examined the 1988 issues of IEEE Software and informally assessed which ideas were “still important today or at least recognizable.” As a result of this exercise, he conjectured that the half-life of software engineering ideas to be around five years.

Certain changes in your software development environment may appear inconsequential in the moment. For example, taking on a different role for the duration of a project or moving to a development team which follows new-to-you practices. However, they can subtly grow your software umwelt in ways that open up the possibility of making significant pivots.

After a short stint programming in COBOL, Rebecca pivoted to a software testing role in an engineering company, and the following year made another pivot to a software engineering role. She didn’t hesitate as she was eager to grow her design and engineering skills. These pivots were easy to make as she didn’t have a lot invested in being a COBOL programmer or a tester. Changes of scenery—or if you’re fortunate, inspiring glimpses into an entirely new and intriguing software development umwelt—can also lay the groundwork for more significant pivots.

If startling enough, exposure to new ideas might even reframe your worldview of software development, and lead you on an entirely new career path. In 1978, Allen attended a talk by Alan Kay titled “Don’t Settle for Anything Less.” Kay showed filmed examples of early versions of Smalltalk and other systems and applications developed at Xerox PARC:

Allen: Kay’s vision aligned with my software design aesthetic…how could I contribute? I transferred into my employeer’s advanced development “labs” in a role that today might be called a Research Software Engineer. A couple years later I had the opportunity to try to make Smalltalk practical for use on affordable personal computers (Caudill and Wirfs-Brock 1986). At first this seemed like an iffy possibility. Smalltalk had been developed running on personal supercomputers not on commodity microprocessors. After several false starts I was successful…

Allen went on to be the software architect of a family of Tektronix Smalltalk workstations, and Smalltalk and object-oriented programming became his career focus for the next twenty years.

We carry our existing umwelt with us. Either we transform our existing perceptions and actions into ones more suitable for our new environment, or we discount them. We’ll certainly have to tune our perceptions to pick up on relevant new cues and then learn how to act on them:

Rebecca: …along came Smalltalk…unlike any programming environment I’d encountered: immersive, graphical, and utterly alien. Its syntax was simple, but the terminology for Smalltalk programming concepts were foreign. I had to translate Smalltalk terms to roughly equivalent programming constructs familiar to me before I could even start to understand what people were talking about…What exactly was a Smalltalk application? What were good ways to think about structuring programs? When should I define my own classes and when should I use existing ones?

When we do make major pivots, we can’t simply flush out our existing software development umwelt and start over. Our brains don’t work that way.

The programming culture you find yourself in can significantly impact the trajectory of your pivot. Fortunately, Rebecca worked in a collaborative engineering culture: A fellow engineer read her first awkward Smalltalk code and offered welcome advice. Programmers, experimenting with ways Smalltalk could be used in Tektronix products, freely shared their insights with her along with their code.

Over the next several years Rebecca immersed herself in Smalltalk, leading Tektronix’ Color Smalltalk product development effort. She came to value carefully designed class libraries:

Rebecca: I came to appreciate the effort it takes to design frameworks …Developing libraries for others’ use demands attention to detail, code comprehensibility, design coherence, and utility. But people won’t know how to use your libraries unless you present a coherent model of how your classes and objects work together and demonstrate how to use them. Working code isn’t sufficient.

Successfully making a large pivot requires letting go of certainty. It takes time and concerted practice to adapt your umwelt to a new environment. Once you do, you will have gained your footing, know how to think and act in that environment, and feel comfortable:

Rebecca: In retrospect, my Smalltalk experiences have had a huge impact on my software development umwelt and the trajectory of the rest of my software development career…I grew to understand how productive Smalltalkers thought, I realized that there were different schools of thought about how to approach object-oriented design. I found that initially thinking in terms of the roles objects play, their “responsibilities” if you will, and how they interact led to significantly different design solutions than if you first focused on how objects responded to events, or what states they were in, or their internal data structure. This led to my inventing responsibility-driven design, teaching numerous design courses, and writing two books about object design.

One of Jordan’s pivots began while she was working as a data journalist in a radio organization. She struggled to bring data to life in radio stories, and became frustrated saying, “Check out our website to see visualizations of the data in this story”—something she knew radio listeners would rarely do. She discovered data sonification, which is the practice of communicating data through sound, and began tinkering with it when, “I learned about a Python package…to turn time series data into MIDI notes by mapping quantity onto pitch…Here, code was a means to creative expression.”

Some pivots are hiding in plain sight, and we don’t know that we are experiencing them. At the time, this seemed like a fun, one-off project—but Jordan would return to data sonification several years later, while getting a PhD in Information Science. Jordan left the field of data journalism, and returned to grad school, because a seed that had been planted earlier—the civic technology project that didn’t meet the needs of the people it aimed to serve—grew and followed her as her career progressed:

Jordan: I loved being a data journalist: In this role, I could combine my love of storytelling with my love of data to find insight and meaning. And I was constantly learning new coding and technology tools to help me do my work, which I found immensely satisfying. Yet I sensed something was missing: Our team spent all of our efforts on reporting and communicating stories, yet we spent almost no time understanding our audiences. What issues did they care about? Were they understanding the complex energy topics we tried to explain? I left journalism to pursue a PhD in Information Science with [a human-computer interaction] emphasis, so that I could learn how to understand people and how they interact with information and technology.

There, her two umwelt pivots collided:

Jordan:…I created many more data sonifications using all kinds of tools…programming languages, no-code tools, I even developed my own techniques to make “lo fi” sonifications using my voice and body…I found the range of tools just as interesting as the sonifications one could produce with them. I also saw coding as a practice that integrated into a constellation of other ways of creating with data and computation—including algorithmic expression that did not require a computer at all.

The culture you are currently in makes career pivots more or less difficult. It can be hard to see a pivot when you are in the middle of one. You don’t know which pivots will be, well, pivotal, and which will just be bumps in the road. However, a COBOL programmer isn’t fated to be a COBOL programmer. A software engineer isn’t destined to develop embedded software. A data journalist can dive into the culture of academia and find her research niche. If you are itching to try new technologies, tooling, or practices, you can find opportunities to acquire new skills and make significant pivots throughout your life as a programmer.

Distilling Our Umwelt

Prompt: What are the core values involved in how you develop software? What makes you unique as a software developer?

We undertook an experiment to find out if writing and comparing reflective narratives of our personal journeys as software developers could enable us to step outside ourselves and perceive the important details of our software umwelts. So, was this experiment successful?

We think so.

We gained insights into our personal software development umwelts that we previously lacked. We teased out common threads that run through our unwelts and that are likely present in other software developers’ umwelts. But, the concrete details of our unwelts—how they filtered our perceptions and influenced our actions—were scattered throughout our thousand-word narratives. It was all too easy to lose ourselves, and hard to answer the question, “What is your software umwelt?”

So, to continue our reflective journey, we gave ourselves one final challenge: to distill our software umwelts down to their cores, to craft a kind of personal software developer mission statement:

Rebecca: The foundation of my software umwelt is curiosity. It drives me to explore new things and immerse myself in new environments. I can be uncomfortable and uncertain of my abilities, while at the same time believing in my ability to successfully navigate new environments. Becoming comfortable with being uncomfortable leads me to find ways to adapt, grow, and stretch my ability to perceive and act. I never hesitated to research design options or ask other developers questions. My ego isn’t tied to figuring things out myself. I’m good at pinpointing key aspects in new environments, processes, or practices and explaining them to myself and others. My outsider’s perspective, along with my design values and practices offer unique and valuable insights. I can zoom out to establish the bigger picture of the overall system architecture, or dive into details and tweak the software design, processes, techniques, or practices. And then as a communicator, I write papers, essays, and books.

Allen: Software is my creative media and programming is an intellectual activity that can be done even in the absence of a physical computer. I’m a systems programmer. I value technical diversity, expect ongoing evolutionary change, and relish radical innovations. Lateral thinking is essential for software innovation. I believe that software exists to support humans and human activities. It should be approachable, understandable, consistent, and comfortable to the humans that will interact with it. I’ve come to understand that programming is model building. I can build software models of real and imaginary worlds. It’s all the same to a computer. Programs are built from layers of abstractions that are ultimately rooted in the numeric manipulation capabilities of computers.

Jordan: My software umwelt is tightly coupled with my familial umwelt, and is a matter of legacy and identity. It has resulted in pride and curiosity. Writing software requires a type of thinking that we don’t often encounter in other dimensions of our lives. We need to empathize with how other people relate to programming. There are many ways to program, and embracing them leads to broader and deeper perspectives and ways of doing things. Software development is a sociotechnical system. I’m always looking at systems, from a standpoint of trying to figure out what people and tools are required to navigate them. But the real power of software is that we can make things that people use—technologies that change the world. But how do we know that we are making something people want? That they need? That doesn’t harm them? To consider these questions, we must always remember to to pull back and see the bigger picture.

By revisiting and reflecting on your own story, refining and rewriting it, and doing so alongside other people, you can identify what is truly important to you when it comes to software development. By sharing your stories with others, you gain a more nuanced understanding of your umwelt and where your umwelt is similar and different from others.

Join Us in Writing Your Own Software Umwelt Story

The exercise of discovering your own software umwelt is hard. It requires effort and intentionality. But it is worth it. We invite you to join us to reflect on your own software umwelt, and—after flailing through this activity—we offer some advice:

• Use the prompts we’ve provided as starting points. Modify them to fit your history, circumstance, and what you hope to learn.
• Start with descriptions of memorable events. Then, read what you’ve written and reflect on their meaning. Why did these experiences stick with you? What values are embedded in the details that you fixated on?
• Do this with a buddy—or two, or three. Build yourself a reflective community of people you trust and feel connected to.
• This is ongoing work that is never done. Step away from it, then come back. Alternate between modes of inquiry (writing, discussing, reading).

Reflective writing includes both descriptions of memorable events and reflections on their significance. It is subjective and personal. You may not have done this kind of work before, so be kind to yourself as you start writing about your experiences and examining your beliefs, values, attitudes and assumptions that form the foundation of your umwelt.

This essay is a starting point. We hope that software developers, researchers, students, and programmers from all walks of life might use these prompts to uncover, reflect on, and expand their own umwelts. When you do, please share them with us—we can’t wait to perceive them.

Appendix: Full Prompt and Narratives

References