Why It’s Okay Not to Have a Five-Year Plan
During the first part of my Xandr interview, I was asked where I saw myself in five years. Despite making daily to-do lists and setting weekly goals, I had no idea where I would end up in two years, much less five. Five years ago I wanted to be a kindergarten teacher. Five years before that I just wanted to dance in ‘The Nutcracker’ ballet. Five months ago I didn’t expect to spend the majority of my working hours in what used to be my nursery, only to be converted into my father’s office, then a storage room, and then back into a makeshift office for the summer. I also didn’t come into the summer expecting to learn so much and be given so much time to learn.
This summer, I worked on the Direct Order Management team as part of the Espresso Squad’s frontend team. Rather than working on a solo intern project I had the opportunity to contribute to the project that the other two members of the team were working on. This involved redesigning an insertion order form meant to streamline code and improve customer experience. The first feature that I worked on was adding user validation functionality. I added functionality to stop the user from progressing to the next state or screen if they make an error, such as forgetting to enter a name or date. When I started on Monday, June 1st, I had little prior experience working with the technology that summer project was based in. I only knew the basics of JavaScript, had written a few lines using React, had no idea what Redux was, and was a little scared of using Git as more than a tool for backing up my projects in case of a computer crash. Much as I didn’t expect to toggle between working in the makeshift office and at my family’s kitchen table, I didn’t believe that I would be given time to explore and learn the new frameworks and technologies before writing code.
My first tasks took multiple weeks for me to complete because at every stage I spent time learning more about the code base, software engineering best practices, and how the different frameworks and components within the tech stack interacted with one another. Instead of jumping straight in, I practiced creating interactive React apps and using Redux. Redux is used to hold the current state of an app, such as the name entered user. I learned how to create actions, reducers, selectors in order to interact with the application state. Ultimately, I was able to use what I learned when implementing the error handling within the application, creating actions to set and clear errors based on the user’s interactions.
Dispatching an action is how the application state is updated. For example, when the user clicks the “save” button after entering information into the form, an action is dispatched to clear out any old errors that the user may have had so that we can run validation from a fresh state. If the user forgot to enter a name into the form, an action is dispatched to update the application state because the name is invalid. After the application state is updated, the name component will see that there was an error and show text on the screen to alert the user.
Along the way I had to rewrite components, move code around, and abandon original ideas. An original requirement of the project was to display a banner at the top of the screen when more than one error had occurred. I chose to implement this by keeping a tally of the total number of errors as they occurred as part of the state. My manager showed me how this was unnecessary and that we could dynamically count them when we needed to. We ended up removing the counting all together and displaying the banner anytime there was at least one error. At first I stored the number of total errors made by the user in the state, only to take it out and change functionality after talking to my manager and learning that this was unnecessary. I did not expect that internship would help me learn greater flexibility, but I have become more comfortable with the idea of not growing too attached to my ideas and work.
In the past, my experiences with writing code primarily included project on which I was the sole contributor. This summer I also learned about refactoring and the importance of writing clean code. For example, I had originally implemented all of the error validation in one file to prove that it could work and keep the logic simple. I chose to break the logic apart into multiple files to make the code base easier to navigate for the engineers who will work on it after the program ends.
Nearing the end of the program, I now have more choice over which components of the project to work on and which tasks to take on. I am now in the midst of creating a new screen that allows the user to choose what type of insertion order they want. I am building on what I learned before and creating the UI and some of the functionality behind it. When I accepted the internship offer at the end of January, I was excited to have a plan for the summer but did not anticipate being able to have agency over my tasks.
I came into the summer hoping and expecting to determine what specific role I wanted to work in tech — frontend engineer, backend engineer, product design, etc. Instead, I learned how to work within a team, code in ways that help others in the future, ask for what I want, and reach out to others. I don’t know if I’m that much closer to answering the five year question because there is so much to learn and explore in each sector that I’m not ready to pick one just yet.
