About Me
Hello! I’m Grace Teng, a software engineer who's spent the last few years building and improving large-scale software systems.
I started my software engineering career at Thoughtworks, where I worked on Singpass, a national digital identity platform designated by the Singapore government as critical information infrastructure. These days, I'm part of the SDLC Engineering team at Goldman Sachs, working on development tooling and build infrastructure used by hundreds of engineers.
So far, my work has focused on two major themes:
- modernising legacy enterprise systems
- improving the software development life cycle
Modernizing Legacy Enterprise Systems
Legacy enterprise systems are an interesting beast. Everybody seems to hate them: the code is hard to understand, architectural choices that made sense five or ten years ago are now an albatross around everyone's necks, and the platform they're built on is now two or three generations behind so you can't take advantage of the latest language and runtime features. The temptation to throw out the old code and start anew is strong (and it's also a big mistake).
The problem is, the software works, and it has to keep working. So how do you keep a system like that going, but still improve it in meaningful, thoughtful ways?
To me, the appeal of working on legacy systems is precisely that they're proven. They're tools that are already fulfilling real needs, so the work that goes into running and improving them has a direct impact on real people. As fun as it is to build something from scratch, I get immense pride from taking over ownership of an existing system and diving into the ways I can make it better.
One of my former tech leads once told me, "the code you wrote yesterday is already legacy code." On one dimension, that's pretty depressing. No engineer likes to think that perhaps someone else will come along and cringe at the code they've written, wanting to throw it out and start over. On the other hand, I prefer to think of it like this: the code I put into production today will be there for years. How do I build a system that can stand the test of time?
Improving the Software Development Life Cycle (SDLC)
"Software development life cycle", and its good friend "agile software practices", are terms that mean many different things to many people, so I'll define my terms up front: to me, the software development life cycle is about going from identifying a problem that can be solved with software, to putting that software in the user's hands. As a general rule, I believe this journey should be as short as possible, for the simple reason that the shorter the cycle, the faster the feedback, and the lower the cost of change. My umbrella term for strategies to accomplish these goals is "agile software practices".
Starting my software engineering career at Thoughtworks gave me a massive headstart in appreciating the nuances of a good SDLC: because so many agile software practices were pioneered or popularized by Thoughtworks, I had an early exposure to engineers who were actively engaged in questioning and improving the SDLC and the agile practices of the teams I worked on. Best practices were not cargo-cult sacred cows: they were very much up for debate, and my teams constantly evaluated and re-evaluated their usefulness. On the other hand, bottlenecks – especially technical ones – did not have to be accepted as an immutable reality. They could be removed, or at least widened to speed up the process of software delivery.
I've taken that experience with me to the SDLC Engineering department at Goldman Sachs, where my job is to improve the platforms that help our engineers ship better code faster, more reliably, and more securely.
There are two reasons I care about speeding up the SDLC:
- A team that can deliver software faster has a competitive advantage over its competitors, and it's an advantage that compounds over time.
- As a software engineer myself, I find that a tight feedback loop is just nicer to work with. It's so much easier to enter a flow state when the distance between thinking, doing, and learning feels nonexistent.
I like working in those environments, so I do my best to create them for myself and for others.
The Long and Winding road
I took the scenic route to becoming a software engineer.
Before entering tech, I worked as a documentary filmmaker, an English teacher, and the first customer support hire at a seed-stage startup. Like many people in their twenties, I wasn't sure what I wanted to do.
When Covid-19 hit, some people baked sourdough and some people played Animal Crossing. I speedran Harvard's CS50x course in 23 days.
I started CS50x because I wanted to learn how software worked, so that I could do my customer support job better. The bug bit me quickly: I found it so satisfying to make computers do things!
I decided then that I wanted to become a software engineer. I went on to complete Le Wagon's Full Stack Web Development bootcamp, which led to me joining Thoughtworks as a trainee, and then as a junior developer. While working at Thoughtworks, I studied part-time for my Masters in Computer and Information Technology degree from the University of Pennsylvania, graduating in 2024.
It's not the conventional route, for sure, but I believe the path I took to get here make me a better software engineer. Documentary filmmaking, teaching and customer support all require a lot of empathy, an understanding of what motivates people, and the ability to structure, prioritize, and communicate information. Those skills turn out to be surprisingly valuable when building software, especially in large teams working on complicated systems.