Growth modeling for developers
By
Published: March 07, 2019
For anybody beginning a career as a software developer, we often make assumptions about how to succeed — assumptions that often turn out to be hopelessly wrong. As I've discovered over the last year, growth opportunities present themselves in all sorts of surprising ways, and I wanted to share my experiences, with the hope that you too can learn from my mistakes.
For the past year, I have been working with the independent global news organization Democracy Now! (DN). To be honest, I was disappointed when I was given the assignment. As a recent graduate, my goal for my first year at Thoughtworks was to make serious strides in my technical growth. Conventional wisdom led me to believe that this would only be possible if I were building software for Fortune 500 clients or working alongside a big team of senior developers. Instead, I was placed at a small nonprofit organization with a team of two other Thoughtworkers.
In essence, I unconsciously constructed a formula to determine what my professional growth would look like in a given assignment:
My main responsibility was to pair program with another developer to build out the new mobile apps, which meant that I was deeply involved in the entire development process. While I had no experience with mobile development, wasn’t familiar with React, and was generally confused by JavaScript, I saw this as an opportunity to grow into a strong front-end developer (whatever that means these days).
As time passed, I found myself growing to appreciate these technologies, continuously humbled by the elegance and cleverness in which they approach complex problems. My desire to intimately understand these technologies grew and I found myself spending a great deal of my free time uncovering the mysteries that lay beneath a surface level understanding. I discovered the power of first-class functions, closures, and the virtual DOM, and tried my best to leverage them in our codebase responsibly. I began to feel myself growing — not because of the size of the client or the seniority of the engineering team — but because of my genuine interest in the work, and my impact on the apps.
At the same time, I believe that uncritically following rules is dangerous, which is why I appreciate that we talk about and debate why these practices matter. How can we, as advocates of quality, deliver on our values if we don’t examine what quality really means? Is TDD giving us fast feedback in this particular situation? Does it really make sense to focus so much on unit testing our React components? Why should we embrace a more functional style of programming?
No, we don’t always write our tests first, deployments still stress me out, and we have accumulated plenty of tech debt due to less than ideal design decisions. However, we all understand the importance of software excellence, and we try our best to maintain strong engineering practices, while being realistic about the resources we have.
Following these practices has helped me realize why they are so important, and has made me a better engineer. Having teammates that value quality — and think critically about what that means — has completely changed the way I think about writing code. And because our engineering team is so small and autonomous, the Thoughtworks engineering culture we bring to DN is almost entirely under our control.
I can’t express how important it has been for me to be able to ask questions, admit ignorance, and show vulnerability. When I first started at DN, I was overwhelmed by the number of JavaScript and React concepts I didn’t understand. I spent a great deal of personal time upskilling myself, but some concepts were really tough for me to grasp.
Fortunately, I had an ultra-talented front-end developer as a coach who was happy to answer my questions and provide me with support to further my learning. I never felt judged for my gaps in knowledge, which allowed me to be open and honest about where I was — and where I wanted to be. This support not only accelerated my growth in JavaScript and React, but also opened up learning avenues driven by genuine interest.
DN is an audience-supported news platform, which means that its editorial independence is never compromised by corporate or government interests. I encourage you to watch the show sometime. DN journalists interview experts on current events, as well as many people whose experiences often go unheard.
In today’s political climate, mainstream news too often feels like entertainment, with the same political commentators speaking about the experiences of others. Given the economic ties of corporate media outlets, discerning what is factual and what is not has become increasingly difficult. This is why having independent media is key to a real democracy.
With all of the ridiculous things that happened in 2018, it meant the world to me that I could show up to work every day at an organization that I feel aligned with, writing code for a product I believe in.
These sorts of mental models help me to determine what I really value. Whether it’s how I choose to spend my weekend, how I budget my money, or just trying to figure out what makes me happy, I find it valuable to isolate meaningful attributes. The trouble occurs when I make assumptions about attributes that turn out not to be true. What works for someone else won’t always work for me, and what made sense for me four years ago might not anymore because I’m a different person now. This is why it’s important to continuously question our beliefs and decision-making processes.
And finally, a quick plug: Look out for the new Democracy Now! Mobile apps in the Google and Apple app stores soon!
For the past year, I have been working with the independent global news organization Democracy Now! (DN). To be honest, I was disappointed when I was given the assignment. As a recent graduate, my goal for my first year at Thoughtworks was to make serious strides in my technical growth. Conventional wisdom led me to believe that this would only be possible if I were building software for Fortune 500 clients or working alongside a big team of senior developers. Instead, I was placed at a small nonprofit organization with a team of two other Thoughtworkers.
In essence, I unconsciously constructed a formula to determine what my professional growth would look like in a given assignment:
Growth Model v0.1
Professional Growth = Size of Organization + Number of Senior Developers
While I was pessimistic about growth opportunities at DN, I was excited about the work the engineering team was doing. When I joined, the team’s efforts were focused on the redesign of DN’s legacy Ruby on Rails web application, moving pages from a dated back-end to a refreshed front-end. About a week into my assignment, another stream of work opened around building new Android and iOS apps using the React Native framework.My main responsibility was to pair program with another developer to build out the new mobile apps, which meant that I was deeply involved in the entire development process. While I had no experience with mobile development, wasn’t familiar with React, and was generally confused by JavaScript, I saw this as an opportunity to grow into a strong front-end developer (whatever that means these days).
As time passed, I found myself growing to appreciate these technologies, continuously humbled by the elegance and cleverness in which they approach complex problems. My desire to intimately understand these technologies grew and I found myself spending a great deal of my free time uncovering the mysteries that lay beneath a surface level understanding. I discovered the power of first-class functions, closures, and the virtual DOM, and tried my best to leverage them in our codebase responsibly. I began to feel myself growing — not because of the size of the client or the seniority of the engineering team — but because of my genuine interest in the work, and my impact on the apps.
Growth Model v0.2
Professional Growth = Contribution Level + Interest in Work
Meanwhile, the development of the DN mobile applications picked up. We started moving really fast, cranking out new features every week. DN didn’t pose bureaucratic restrictions on us, and my tech leads gave me a lot of freedom. This meant that I spent my time problem-solving and delivering features, instead of maneuvering through organizational inefficiencies.Growth Model v0.3
Professional Growth = Contribution Level + Interest in Work + Velocity
In my time at DN, I’ve been lucky enough to be part of a team that believes in a strong engineering culture. This can mean so many things, but I think it’s well summed up in this Insights article by Evan Bottcher. My team values practices like pair programming, test-driven development (TDD), continuous integration, and refactoring. These aren’t just buzzwords to us; we incorporate them into our day-to-day lives as engineers.At the same time, I believe that uncritically following rules is dangerous, which is why I appreciate that we talk about and debate why these practices matter. How can we, as advocates of quality, deliver on our values if we don’t examine what quality really means? Is TDD giving us fast feedback in this particular situation? Does it really make sense to focus so much on unit testing our React components? Why should we embrace a more functional style of programming?
No, we don’t always write our tests first, deployments still stress me out, and we have accumulated plenty of tech debt due to less than ideal design decisions. However, we all understand the importance of software excellence, and we try our best to maintain strong engineering practices, while being realistic about the resources we have.
Following these practices has helped me realize why they are so important, and has made me a better engineer. Having teammates that value quality — and think critically about what that means — has completely changed the way I think about writing code. And because our engineering team is so small and autonomous, the Thoughtworks engineering culture we bring to DN is almost entirely under our control.
Growth Model v0.4
Professional Growth = Contribution Level + Interest in Work + Velocity + Engineering Culture
One of the things I dislike most about the tech industry is the macho, self-important superiority complex that so many developers seem to have. Having team members like this can really damage self-esteem, especially for those who experience aspects of imposter syndrome.I can’t express how important it has been for me to be able to ask questions, admit ignorance, and show vulnerability. When I first started at DN, I was overwhelmed by the number of JavaScript and React concepts I didn’t understand. I spent a great deal of personal time upskilling myself, but some concepts were really tough for me to grasp.
Fortunately, I had an ultra-talented front-end developer as a coach who was happy to answer my questions and provide me with support to further my learning. I never felt judged for my gaps in knowledge, which allowed me to be open and honest about where I was — and where I wanted to be. This support not only accelerated my growth in JavaScript and React, but also opened up learning avenues driven by genuine interest.
Growth Model v0.5
Professional Growth = Contribution Level + Interest in Work + Velocity + Engineering Culture + Support
DN is an audience-supported news platform, which means that its editorial independence is never compromised by corporate or government interests. I encourage you to watch the show sometime. DN journalists interview experts on current events, as well as many people whose experiences often go unheard.
In today’s political climate, mainstream news too often feels like entertainment, with the same political commentators speaking about the experiences of others. Given the economic ties of corporate media outlets, discerning what is factual and what is not has become increasingly difficult. This is why having independent media is key to a real democracy.
With all of the ridiculous things that happened in 2018, it meant the world to me that I could show up to work every day at an organization that I feel aligned with, writing code for a product I believe in.
Growth Model v1.0
Professional Growth = Contribution Level + Interest in Work + Velocity + Engineering Culture + Support + Belief in the Product
This is my current model, and it is how I plan to evaluate future opportunities. As I progress in my career and work with different organizations and teams, I’m certain this model will change. The importance of each attribute will evolve, and new ones (now overlooked or hidden) will emerge.These sorts of mental models help me to determine what I really value. Whether it’s how I choose to spend my weekend, how I budget my money, or just trying to figure out what makes me happy, I find it valuable to isolate meaningful attributes. The trouble occurs when I make assumptions about attributes that turn out not to be true. What works for someone else won’t always work for me, and what made sense for me four years ago might not anymore because I’m a different person now. This is why it’s important to continuously question our beliefs and decision-making processes.
And finally, a quick plug: Look out for the new Democracy Now! Mobile apps in the Google and Apple app stores soon!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.