My grad experience through the perspective of the modern knowledge worker: the text editor

This article is a reflection on the past 6 months of my Capgemini graduate program journey from applying as a graduate to managing articles for the 2018 #Gradathon campaign.

Publish date:

My interviewer and I sat in bright red chairs surrounded by colourful illustrations on whiteboards. Bubbly background music hummed with the shuffle of case studies scribbles on Post-it notes and, bizarrely, the scrabbling of Lego pieces, all from the different surrounding activities that made up the assessment centre for Capgemini’s February 2018 intake.

The printout of my resume the interviewer held was in stark comparison uncreatively black, white. Calibri. Large fonts and generous in-line spacing distributed blank space.

That copy of my resume – detailing the soft skills from my education in chemical engineering, my two years post-graduation tutoring as an independent private tutor, and my scattershot experiences before and in between – had been sent out to a number of other companies. It was the latest iteration of a polishing exercise, where I swapped out a list of everything I had learned for a list of everything I had achieved.

Each of those experiences had a story behind them. It had taken time and thought to unpack and polish those stories. Some of it had paid off; I rattled off examples I had prepared about innovation and leadership with ease. But other questions pushed me off script.

“So you ran your own business for a while, I get that. And you seem to enjoy it. But what’s stopping you from just continuing if you’re doing well?”

I answered truthfully:

“I’ve been working on my own the whole time. I can see the limits of what I can do if I keep on going like this. Capgemini says it’s all about collaboration and team spirit, and the scale of what you can do with a team is so much better. I would like to be part of that, I think.”

Version savagery

My first engagement after my acceptance to the graduate program saw me work with a team of ten for fifteen weeks. Much of the meetings and collaboration was done in a repurposed server room on the client site. We checked in five days a week going up the elevator and past the desks to the corner with the heavy door. The vents that usually provided cooling air to heat-laboured racks that were no longer there couldn’t be turned off, and the walls were the sort of off-cream that would fit into the setpiece of a sitcom depicting the death of the 90’s – still, our team became tightly knit, and ultimately I got what I had said I wanted.

One key learning, even before that project began, revolved around the Scope of Work. The only other experience I had that came close to it was a first-year tender-writing exercise revolving around a “contract” to build a bridge out of popsicle sticks. The SoW defined what we were there to do. It defined what we had to deliver, how, and by when. It is crucial in setting expectations, which is why we spent several days coercing it into shape.

The term technical audit works well as a summary of the project. Before embarking on an ambitious migration out of their datacentres and into the cloud, the client needed to consider their application ecosystem. My team were there to collect and produce objective (technical) and subjective (business) advice that would be used to inform next steps such as business cases and wave planning.

Describing it in a way that was comprehensive yet not limiting was part of the challenge. Again, the SoW outlined expectations and deliverables, which meant that it was the consensus between client and team. Suffice to say for the former that a lot of back-and-forths was required, as is the way of all good collaboration; as two of our workstream leads were coming in from offshore, we had to be especially mindful that we were clear on what it was we could do. The last thing we wanted was to sell milestones that we couldn’t achieve.

Working under our manager, who was the global lead for the project, I and another graduate projected that Word document up on the screen, and we would chip at it section by section. The depth of thought and experience demonstrated by him was evident – he handled the unenviable task of predicting what requirements we would need, and projecting what risks might show up (and the mitigation and contingencies against those) in the face of great uncertainty.

How do you model value? How do you model complexity? What would give you the information that went into those elements?

Client demands formed the beginning, our offering formed the middle, constraints and assumptions and the requirements formed the end of an iterative rewrite cycle.

Something that stuck with me was how he would save a new copy, versioning each document in increments. It was a product of his origins in the operations and monitoring space and passion for open source. He would joke, as we initially saved over old versions with Ctrl+S, that we were “version savages”, overwriting archival details and changes into oblivion. To us, it was the only way we ever knew; to him, it was suboptimal practice.

The insistence on habitual versioning would come in handy in a number of occasions afterwards – immediately, when we needed to recall exactly what we had discussed with the client in previous iterations due to a misunderstanding – and beyond, when later shared deliverables, mostly gigantic spreadsheets, would fail to sync across simultaneously working colleagues or outright crash and corrupt. Those are not stories unique to me, as any student with a RAM deficiency can attest, but the feeling of relief when we finalized and had it signed off – offhand as it may be, it felt like I had given birth to a child that I had not particularly wanted, but would love nonetheless.

vim hello_world

Immediately after that, we made up the DevOps capability.

That is to say, I, my fellow grad, an application architect and our manager formed the DevOps capability. All four of us.

To be fair, this arrangement was temporary while the business reoriented and streamlined its more technical competencies, and we would have another six added to the group a week after. But that week, where we each made up a significant fraction of our offering, we got to work.

As mentioned, our manager had a storied background in IT infrastructure and was a big fan of open source technology. Now, he could drive a vision where Capgemini brought the power of open source tools to its clients, and Ansible was at the heart of this vision.

To keep this necessary aside short (if you’re familiar, you can read anyways to leave corrections in the comments): DevOps seeks to reduce the friction and siloed thinking between development (where you write code) and operations (where you deliver service). There is some overlap with continuous integration/delivery (CI/CD), which are self-explanatory: I personally like the phrase ‘code to scale’.

Ansible, meanwhile, is ‘simple IT automation’. It allows you to spin up infrastructure to house applications by writing code in a relatively straightforward syntax called playbooks. Run a playbook that, for example, creates a database on the cloud, and poof – you have a database on the cloud. Run a playbook that makes a virtual machine on the cloud, loads Docker, tells Docker to grab a copy of Jenkins, which in turn sets up Gitlab and makes builds from code entered into that Gitlab…

Add a test cycle to that, and you had a seamless magical automation machine where a client could point to their cloud environment, and watch as an entire toolchain sprouted.

But before that could happen, someone had to write up the Ansible playbooks and get them to work. And before someone could write the playbooks, we had to learn how to write.

That fateful morning, we booked a boardroom, invited a few more interested grads, and did a crash course in Ansible. We worked off Ubuntu virtual machines on a free trial of Google Cloud Platform (bless their in-browser SSH console), downloading all the requirements Ansible needed to run – think Python, modules of Python and libcloud – and then it was time.

Vim is a text editor. That is to say – you write files in Linux with it. It does not come with much of an interface. It does not even tell you that when you start up Vim, you cannot actually start writing. You must tap “i” to prompt the editor to switch to writing mode. Not pressing “i” makes for futile strokes and, if you were copy/pasting content instead, chunks of missing characters.

It was a far cry from Word. The biggest thing that gets me even today is the lack of a “click to navigate” function. To go from line 3 to line 10 I had to tap the arrow keys; I often tap too much and overshoot. The basic shortcuts – how to save the file, how to quit without overwriting – I got down quickly, but ones I would have found useful – deleting whole words or lines – elude me still, and I dumbly ply the “Delete” button and watch as the flashing blocker swallows up the letters one at a time.

And yet, I got it immediately – the direct power that underlay the simplicity. I could write programs in this, and the lack of bells and whistles meant that all my focus went into that. No fussing with fonts, no dithering with margins. The tool that I had produced innumerable pieces of work with, and indeed the only tool that filled that niche in my life up until then, suddenly seemed clunkier, slower, more bloated.

Alternating regularly between the two as I documented what worked sharpened the difference, and worked as a metaphor for how, just 6 months into my graduate journey, things had changed.

If it wasn’t evident already, I did not have a coding background when I started and had not envisioned myself doing technical work at all. Yet watching the console spit out red-on-black error paragraphs as I tested my playbooks made me feel all the more empowered. At a glance, my screen looked no different to Franklin’s as he desperately tried to “restart the mainframe” while lava sloshed over and through the walls in Jurassic World: Fallen Kingdom. It was, very simply, cool. And switching between Word and Vim, I could feel my perceptions shift, not just about the text editor of the moment but of the technology I used and how I used it. As those shifted, so did my vision for my career path.

Resectioned and reworded

With Capgemini’s 2018 Gradathon campaign, I got to fulfil a small fantasy of mine – to run an editorial. I am passionate about writing; the only thing that tears me away from my mobile game addiction on my daily commutes is Medium. In fact, my readership on Medium lasted longer than my interest in cryptocurrency markets, which was what got me on to Medium in the first place.

I knew from the start that I wanted to edit. I contributed to a small writing community while in university, offering advice to whoever asked for it and stuck around long enough for my feedback style to mature to a point where I was confident that I could help. When the call came for someone to take charge of interest articles, I put my hand up.

Through the process, the biggest challenge was not the editing, but everything else around it – competing priorities, ongoing interests, pesky distractions. I knew from practice that I wasn’t the fastest writer, but that had never been a problem when writing was a hobby. Now, an hour spent on writing was an hour away from the console, an hour away from a backlog of online learning spanning from cloud certifications to chatbot design. Time was limited. It always had been, but this was the first time I had felt it. Even when I ran my own business, I took for granted the amount of time there was in a day – since I operated largely from home, work and life sloshed together into a big pool that I could distribute however I wanted. Needless to say, time was much less constrained while I was in university. In the office, however, eight hours was eight hours, and one of them was for lunch!

The difference, I think – time management is shaping up to have a lifelong learning curve for me – is that unlike before, I now had multiple interests. Outside of work, I am quite singular about my habits. I devote afternoons and evenings to a diverse range of interests, be it food festivals around Sydney, Haruki Murakami novels, or tormenting my cat with my mediocre piano skills. But rarely do I devote that time to more than one thing. Now, I had to work with blocks of time. I had to be willing to let go, whether I was coming close to making a breakthrough on a problem or just enjoying myself and to position the work to be in a state that I could pick up and continue the next day.

Being the point of contact gave me opportunities to collaborate with other graduates outside of projects or scheduled learning opportunities. The articles I received range from the highly technical to the hopefully helpful. Put together, they give a glimpse into the diversity of topics our grads concern themselves with. Behind every other article, you’ll read with the #Gradathon hashtag, are interesting conversations and moments of mutual challenge. Ranging from whether Namecoin was an application of blockchain to whether or not studying STEM is suffering, I can assure you that if there’s a comment section and you have feedback you want to share, the authors are eager to read it. Please do check them out.

As for this, and many other stories like it across our many socials, I hope it provides you with a brief look into the life of a Capgemini graduate. We can’t promise that we can give away any secrets, but if you see any of us at events like The Big Meet or find us across your Linkedin, say hi and chat! Gradathon is one such time where we’re made aware of our role in encouraging candidates to apply, so take the opportunity and see if a life like this is something you envision for you.

Discover career opportunities over at our career page 

Related Posts


The 5G revolution series Part 1: Why telcos should target the B2B opportunity

Pierre Fortier
Date icon June 12, 2019

Capgemini research reveals that a majority of manufacturing leaders believe 5G will be a key...

How to define complex use cases and implement them in your SIEM/SOC project

André Hohner
Date icon May 30, 2019

Use cases are a key component of every SIEM. However, their complexity makes organizations...


By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.


Close cookie information