Following the advice in Brandon Walsh’s warning, “anything that gets in the middle will keep you from blogging,” I simplified the steps to update and publish my website because the situation was getting a little miserable.

GitHub Pages is a great way to host your static sites free, if you don’t mind keeping your code public. It’s an especially smooth experience if you produce your site with Jekyll because it enjoys built-in support on this hosting platform. In other words, when you upload your Jekyll code to a public GitHub repository and activate GitHub Pages, the site will deploy automatically and become live within seconds (unless something goes wrong).

But I am using 11ty, a JavaScript-based framework, and while it’s common to host other kinds of static websites on GitHub besides Jekyll, it does add some extra steps. I was so close to publishing my website, I really didn’t want to stop for the ideal solution, so I created one main branch for deployment and another deploy one to serve the html files produced after 11ty parsed my root directory. This meant manually copying, pasting, and replacing old html files for newer ones between these 2 branches to keep the site updated. It got old quick. So quick changing this workflow became my top priority issue within the site.

Thankfully, I complained about it to Brandon at the Lab the other week, and he suggested I look for an 11ty version of a “Rakefile,” a document he uses to include custom website build and deployment instructions in his Jekyll website. Some digging pointed out that GitHub Actions might be the easiest way to go.

Using Actions involves changing a setting in your repository, a 1-line edit to your package.json, and a YAML file describing your desired build and deploy workflow for GitHub Pages to host your site. True, I didn’t know what my desired workflow file should look like, but Google turned up a useful Mini-Tutorial in the 11ty documentation that explains the full deploy process and shares a YAML example ready for you to copy and use within your web project.

This worked, but I really didn’t know what was going on in the file at all, so I asked Claude Code 2.1.109 to make me a deploy.yaml file to deploy my 11ty site on GitHub Pages. The file that came out, frankly, works just as fine for my purposes the sample one. One notable difference was the simplicity of Claude’s YAML vs the sample one in the official 11ty documentation, which is thorough and filled with many options to understand.

I stuck to using the sample YAML in 11ty’s docs because it’s safer and adds caching to the deploy workflow, for example.

I kept the simpler Claude Code deploy until I felt that I had a general sense of what was going on in the file. GitHub’s “Workflow Syntax” page was key to understanding what is going on in the file, and what the commands mean. It’s messy, though, and hard to navigate. I skimmed through 75% of it before I found the answer to one of the questions that bothered me the most: “What the heck is that actions/setup-node@v4 doing?” I knew it was setting up Node.js version 4, somehow, but how? Turns out it’s accessing and serving a contained version of Node used by through GitHub Actions to parse and deploy my 11ty site.

name: Deploy
on:
  push:
    branches: [main]

concurrency: 
  group: pages
  cancel-in-progress: true

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - uses: actions/configure-pages@v5
      - run: npm run build
      - uses: actions/upload-pages-artifact@v3
        with:
          path: ./_site

  deploy:
    needs: build-and-deploy
    runs-on: ubuntu-latest
    permissions:
          pages: write
          id-token: write
    environment: 
      name: github-pages
      url: $
    steps: 
      - uses: actions/deploy-pages@v4
        id: deploy

Figure 3. Code block with the simpler GitHub Actions workflow generated by Claude Code 2.1.109 to build and deploy my 11ty website. A.k.a. deploy.yaml

I. Have. A. Website. ✨ https://winnieepm.github.io/ ✨

As this academic year is coming to an end, I don’t have a dissertation to defend yet, but I did publish a public website freely hosted on GitHub Pages—it’s been three years in the making. What took so long, you ask? A combination of reasons, with two that stand out. One, I couldn’t make up my mind about the method for making it or the design. Too many choices, possibilities, tools to try, strong opinions, use-cases. Two, I chose to code my own website, and self-learning coding while you’re a full-time doctoral student in the humanities brings its own significant systemic and personal challenges: there’s no reward for the quirky extra major, at least not immediately. So, why do it at all?

I chose to explore minimal development stacks because building them forced me to learn how they work. At what point is HTML and CSS alone not enough? Why do you need a framework? What decisions draw projects to content managers or static websites? When is a database required?

The ubiquity of websites, especially for professionals today, ticked my curiosity to learn how they worked to produce an online presence of a person IRL, but popular options like Wordpress, Wix, and Squarespace, offer limited out-of-the-box theme options to display and manage your content. Also, it will typically cost you to access their full library of design and layout resources to make a personalized website that uniquely represents you and stands out. Each of these also require constant updates to ensure the site’s safety and functionality, which means your website can easily break, or be exposed to cyber attacks, if you fall behind updates.

Though the CMS (content management system) route makes sense for many, I had questions about web sustainability, development, and design that drove me instead to pure HTML/CSS pages, and static site generators (SSGs), for making myself a website I could style and organize at will locally. SSGs take in textual content written in markdown, your designated layouts, and data, they then process all these files locally to produce a version of your website in a set of HTML files ready for hosting. This simple production pipeline makes for fast, flexible, and design agnostic webpages that are so small in file size they can fit in a 1GB flashdrive.

But the benefits come with a steep learning curve. It requires great learning effort, if you’re unfamiliar with coding, and a significant time commitment. For collaborative projects, creating different user access levels and credentials is not supported and would require coding a custom solution. You also need to use a code editor for updating the website, which is something not everyone is comfortable doing or needs to learn.

I built and continue developing my own portfolio website using the 11ty framework, an SSG based on JavaScript that has become popular in the past years because it’s easy to set up, compared to others like Jekyll, and it makes no decisions on how to style your projects out of the box. Honestly, I wasn’t aware of how long it would take me to learn all the things I’ve come to learn up until this point, but I also don’t regret it because I have been able to support other digital projects just because I have spent enough time banging my head against the wall to setup up and customize 11ty. If I had to do it all over again, I would, though I’d focus more on simplifying my goals and tasks, rather than setting out to accomplish really ambitious projects that constantly feel out of reach while you’re working on them.

Anyway, I made my website. It’s live, it’ll keep growing, and it’s mine.

Lately, I’ve been thinking a lot about that canonical debate around depth vs. breadth in digital humanities (DH). I remember initially my reaction was feeling that “true” DHers should be both, that this was an aptitude anyone could and should develop in the spirit of the discipline.¹ After much method trial-and-error, I then grew frustrated that I hadn’t found “my thing” and disappointed to think I could only do DH in breadth, not depth. I was bound to a path instead of choosing one. Eventually, I decided I didn’t care for the division at all.

Lately, though, I’ve started wondering, what if the question has multiple axes acting simultaneously? What if breadth leads to depth, the opposite happens, or something else altogether? What if, instead of choosing a path, it emerges, for each one of us, from our own individual way of sharing, problem-solving, organizing, and researching?

In my “failing” to become an expert at one single thing calling out to me, I had no choice but accepting and recognizing the value of breadth, and inevitability of failure—another core DH moment—even if my perceived failure was personal in nature.² But the beauty of “rock bottoms” is that they create an opportunity for radical change because one’s ego is finally humble enough to give up on what isn’t working and engage in earnest reflection, even start over. ON/OFF. Unplug and replug. It’s a time to accept losses and reassess them against growth, assets, skills, experience, effort, connections. What did you learn in the process? In DH, the process is key.³

Through the process, I learned I’ve been wrong all along: depth & breath are really two sides of the same coin. What separates us should be instead the base principles for a constructive bridge uniting DH inquiry. I used to think that not knowing and being new to the tools of an environment was a disadvantage (breadth+1), but it turns out specialists (depth+1) often don’t remember what a beginner feels or needs, precisely because they have intimate knowledge of their fields. The specialist (depth+1) is always iterating over their craft, perfecting techniques or creating new ones, deeply connected to the innovations of peers, organizations, and entities influencing their work. Generalists (breadth+1), typically, pay attention to what’s going on in multiple fields, who’s working where, what is the budget distribution, how do you get more students in to apply for your programs, how do you process their applications. DH emerges from a delicate act of balancing out critical responsibilities among experts of both kinds, each deeply attuned to their own and each other’s tasks.

Revisiting this discussion with recent insights, I realized that, as far as the depth & breadth goes, I am through and through a digital humanist in breadth (of course, an oxymoron). This is how my brain works. I have a good instinct for quickly finding unusual connections between topics, and a curiosity for learning anything, so I end up knowing a little bit about many things, not much about anything at all. I used to badly resent this indecisiveness in my learning pattern, the inability to choose and stick to one thing passionately forever, but I have been reworking this perspective to understand that what I am is flexible, curious, nimble. This is a quality that makes me good at handling unknown situations, at learning how to learn new things on my own, and at translating that knowledge of the learning process to expert audiences.

And yet, over time, I have found myself going back to specific projects, questions, topics. I keep thinking about design, minimal computing, pedagogy, infrastructures, technology, small datasets, and collaborative work, for example, over and over again in recent years. These are now inescapable research areas for me. Won’t this path of ceaseless returning eventually lead to depth as projects grow and change from recurring personal concerns, interests? Maybe we all become breadth/depth hybrids if we spend long enough earnestly engaging DH work, which is kind of pretty, it means connection awaits at the center where both axes intersect.

It’s 2025 and too many of those enrolled in humanities PhD programs¹ still think they’re going to land a tenure-track faculty position in higher education. Yes, Faculty² members have been slowly facing the crisis of the academic job market, but even the most supportive ones are strapped for the resources, field knowledge, and the necessary time to effectively help PhDs navigate this landscape. Graduate curricula rarely includes comprehensive career training or coaching. This task falls almost entirely on academic advisors, many of which barely have time to keep up with their own work. How will they have time to educate their students about non-faculty careers? What happens if the tenured advisor isn’t even interested in engaging with the core issues of this challenging landscape? Who is going to support the PhD worker then?

Part of the academic job market problem is that we struggle to rethink the meaning of a successful PhD graduate in our times. We,³ scholars especially in the humanities, don’t know enough yet about non-academic networking to know or show what kinds of jobs, lifestyles, and interventions the humanities can create beyond the university. This is a challenge that haunts me, personally, as I’m soon-to-be in the job market for non-faculty academic jobs. It is also one that feels fundamental to answer for all of us who worry about the future of humanities scholarship and pedagogy.

One of my internship tasks this semester was updating the alumni data for two programs sponsored by the Scholars’ Lab: the Digital Humanities and Praxis fellowship programs, both yearlong DH-training opportunities for PhDs at UVA. Though there were preceding initiatives, the current structure of the Digital Humanities Fellowship is in place since 2007, and the Praxis Program since 2011. By now, there’s 121 combined alumni, many of which have graduated and taken on different positions. Some of those make great departing points for re-envisioning what success looks like for PhDs.

For example, humanities PhDs, did you know you have been gaining project management competencies all this time? I’d never heard about this field before I joined DH, but it turns out all that invisible work you put into completing your program gives you transferable skills that are highly valuable in project managers. Critical thinking, independent research, writing, pedagogical training, communication, and problem-solving are some of the core abilities we develop over time as we comply with the graduate and hidden curricula.

There’s also people who work as digital librarians/specialists within academic libraries. They engage, on different levels, with the training and education of known and emerging technologies, particularly those on the web. Think curriculum development, workshops, mentorship, library guides, project consulting, archival research, research assets creation and management. Are these abilities not akin to the training we acquire throughout the PhD?

Curators, consultants, artists, freelancers, programmers, developers, faculty, teachers, life coaches, housemakers, writers, editors, program directors. Those are some of the other careers and pathways of Scholars’ Lab alumni. Faculty and teaching-heavy jobs are only one genre of options. Why do we romanticize those positions and disproportionately teach PhDs to prioritize them? There’s so many things a humanities PhD can be. Why do we insist on feeding the neoliberal academy with our own bodies?

Graduate students workers are a lower class form of contingent labor in higher education, although a privileged one. Grad workers supply essential labor to universities for a fraction of a faculty/lecturer salary. As a direct consequence of their contingent status, graduate professional development is rarely a priority in the daily operations of a doctoral academic curriculum. Institutional needs always come first.

Many grad workers come into PhD programs unaware of this dynamic and how it decisively shapes our professional outlook during and after the program. Others, like me, have been exposed to its reality through sour personal experiences and conversations with mentors, colleagues. Even so, I know we remain at least partially in the dark about the ramifications that being cheap, contingent workers have on our role and responsibilities as workers. We graduate without fully realizing the extent to which being employees in a knowledge company affects our ability to afford basic necessities, like rent and food. Partly, this happens because cloaking the commodification of higher education has become part and parcel of academic culture.

For me, it was in the digital humanities community (DH) where I started feeling more like a colleague than a student. In this space, I met people who helped me see, understand, and navigate my position as a higher ed worker. Why is it that some realities of labor are more visible in DH spaces? Why is it so hard to talk about labor in academic ones?

Academic scholarship, for historical and cultural reasons, holds the allure of being a virtuous pursuit, the always-noble goal of producing and managing human knowledge. Scholars are the watchful guardians of humanity’s archive—or that’s supposed to be the idea. Many apply to grad programs hoping to join a knowledge-driven guild. In reality, joining this grand purpose also means inheriting a set of intellectual hierarchies, values, and practices that have as much to do with oppression as they do with knowledge-production and pedagogy. It is easy to forget that, after all, the university is a centuries-old product of early Christian European ideas of knowledge-making and learning. This means that the dedication of the “Academic Ivory Tower” to the pursuit of knowledge also includes strict models, formats, and biases about what scholarship means and looks like, who can produce it, what makes it valid, and how it turns into knowledge.

This long tradition of academia as a space for intellectual exchange is what still draws many of us to its campuses, what compels us to dedicate long hours to reading, writing, thinking. We collectively subscribe tacitly to the belief that the university is a safe site for intellectual exchange and learning. Such an idea hides institutional interests and dealings in politics and funding to, instead, present the university as an intellectual safe-haven. The hidden underbelly reveals a for-profit institution looking to capitalize its assets (human and otherwise) to their maximum potential, often as cheap as possible.

In this system, the love and devotion for sharing knowledge that is inherent to the role of lecturers, faculty, and graduate PhD workers becomes entangled with the amount of labor they individually generate for the university.¹ But these conditions aren’t immediately visible in everyday life. It takes time, exposure, good guidance, and effort to see the small ways in which they end up significantly shaping career outlooks, especially for grad workers. You’re caught between being a student (someone who takes courses), a teaching instructor, a research assistant, and a researcher-in-training. You’re meant to defer to your advisor and/or department when you take on new commitments, projects, applications, and they sort out the administrative side sometimes without much explanation. Institutional rules and regulations are not to be your immediate concern, much less your focus. You’re theoretically expected to fully focus on your research. But these rules hold the bureaucratic and capitalist nuances that govern the existence of your position as a grad “student” worker.

DH offered me, instead, a space to meet, listen, and learn from a community of scholars that do not all hold traditional tenure-track placements. Many are librarians, research specialists, programmers, admin directors, or officers. Regardless of job title, these are the kind of worker hired generally under the label of “staff.” Their salaried conditions play a daily role in their workplace interactions and their position’s descriptions are more granularly described than “graduate student” or “dissertation committee member,” for example. This varied constituency, in turn, supports the development of DH’s overt disciplinary concern with the job crisis in higher education at a time when traditional graduate school curricula aren’t evolving quickly enough to protect graduate workers from the crisis. Professionalization in DH goes hand in hand with discussions about pedagogy to address job uncertainty, job market survival skills, alt-ac opportunities/training, and hidden curriculum issues.

A landscape where labor is frequently discussed creates the space to consider the necessary individual, personal, material needs that we each require to become fulfilled employees amidst current broader issues of social and economic decay. A space that acknowledges multiple forms of expertise, abilities, and needs, also highlights that one single person—no matter their desire and experience—is incapable of single-handedly supporting a grad worker’s growth as a professional. DH pushes grad workers to seek and foster a community of colleagues to navigate the brutal job market where the traditional graduate curriculum dictates graduate student workers should always do what their advisor says.

Last week, I started an internship at the Scholars’ Lab made possible by the PhD+ Program at UVA. This means that, during the Fall semester, I get to support the student programs, Lab initiatives, and labor of the folks that over the past four years have modeled for me how scholarship can be a liberating personal and professional practice, a genuine exercise at human connection.

The position involves a series of tasks with varying levels of depth that touch on curriculum development, pedagogical practice, documentation development, consultations, and institutional regulations. These topics speak directly to my professional goals to hone in skills and gain experience working in positions that support and develop scholarship within the realm of digital humanities, going beyond the space of academic departments. It is a tailored internship that was collaboratively conceived between my internship supervisor, Brandon Walsh, and me. Brandon is the Head of Student Programs at the Scholars’ Lab, and working closely with him in an official capacity has been a dream for a long time now. I could not ask for a better boss, mentor, and friend to guide and support my professionalization journey as I take steps to position myself as a young working professional about to enter the job market, rather than as a student.¹

Brandon’s ongoing commitment to critical digital pedagogy, as a philosophy and active practice, has profoundly changed my own relationship to learning and teaching. Through mentorship meetings, article discussions, workshop practices, and collaborative writing exercises, our collaborations were a catalyst I desperately needed to begin imagining and theorizing what I want in my personal relationship to pedagogy as well as the shape of the pedagogical spaces I envision fostering.

While this inaugural blog post highlights why this internship is meaningful to me, as a 6th-year PhD candidate, Brandon’s latest blog post reflects on the role of a supervisor and shares details about the main tasks I will tackle over the semester.

My main goals are to strengthen my ties to this community and make new friends, though I also anticipate making plenty of mistakes as I make my way to small wins and achievements. Grappling with failure and process are, after all, essential parts of digital humanities scholarship and labor due to their historical connection to coding, as Quinn Dombrowski has pointed out. I welcome the attention in DH to individual working experiences, especially when it addresses navigating failure and reflecting on labor processes, as a methodological sandbox to practice patience with myself. Within the internship, I plan to exercise this knowledge to continue unlearning the culture surrounding academic hierarchy that is based on degree, tenure, rank, or institutional influence. I want commitment, accountability, labor, skills, and consistent kindness, instead, to guide who I come to respect and whose respect I earn, regardless of ranks. Moreover, I want these to be the values I use to assign my own labor value.

At a time of uncertainty, fear, and massive funding cuts, I envision my PhD+ internship at the Scholars’ Lab to be a nurturing space of experimentation where I can shape the kind of laborer I want to become, post-PhD, in a crumbling social environment that desperately cries for sustainable practices of care.