Halfway through university, I was forced to drop out due to lack of funds. I then spent ten years cycling through different careers (or, perhaps more accurately, attempts at careers). Throughout that time, I worked multiple jobs that did not truly interest me, none of which were in tech. Moreover, I also came out as transgender and transitioned during that time. When I finally decided to try to enter the tech industry, it felt like there were countless barriers against me. However, I was able to complete a coding bootcamp program and get hired as a software engineer. This article is my attempt to catalog some of the most important lessons I learned over the last year: my first year in tech.
When I was first hired at my software engineering job, it was quite an adjustment. The pace, the process, and the style of workflow were all brand new to me. Initially, my approach was to create a comprehensive layout for every aspect of a project: I hoped that this would allow me to conquer all possible uncertainties. Soon enough, I learned there’s a reason the “waterfall method” doesn’t work in software. I struggled with feeling that I wasn’t making progress and did not have a grip on what was going on in a project. However, I came to understand that learning and identifying obstacles is progress. In fact, it’s the entire point. This is part of the reason Agile is such a widely used methodology: it enables me to adapt to changes on the go rather than attempt to stick to a rigid, linear plan.
Struggling in this process is the point—and I sure got the point. At some point during my many career attempts, I got it into my head that struggle equals failure, but in reality, that couldn’t be further from the truth. This may be some remnants of working in physical labor for a large part of my life, but my new career involves thinking and strategy and, as such, it has required me to reframe my perception of progress and success. Working in physical labor jobs for a large part of my life, my managers instilled mantras into me like, “If you have time to lean, you have time to clean.” In those types of jobs, it was understood that no physical labor being done means no work being done. In the last year, I had to become a lot more comfortable with taking time to research, talking to myself, asking others questions, going on a walk to think something over, or visually mapping something out to get a better grasp of it.
For the first time in my life, I’m in a career where I feel that my input is actually valued. Now, I feel empowered to express myself. I consistently speak up in discussions and meetings. I often bounce ideas off coworkers. It’s easy to forget to give other people feedback (especially praise) out loud in public, but I have learned how important it is to make a concerted effort to do so whenever possible.
Software development is a team sport. Relying on and supporting each other is paramount. It is the same with code: it is only useful when others can understand it. After much frustration, I have grown to appreciate that code quality is a constant pursuit, but understandable code is the ultimate goal. Code that is “inefficient” but easily comprehensible is infinitely better than super slick code that no one else can figure out.
I’m incompetent. I’m a fraud. I try to blend in, but soon enough, I’ll be exposed and exiled. Everyone in the office can smell my fear. They won’t fall for my act much longer. My manager and my coworkers frequently check in with me and assure me that they want to help, but I know better—they’re hoping I’ll fail. I must instantly know everything. Making a single mistake is unacceptable. I shouldn’t need to learn as I go. Without a doubt, my days at this job are numbered.
…Unless I’m wrong. Imposter syndrome is a hell of a drug.
For my own sanity, I try to remind myself that no one really knows what they are doing. It’s easy for me to assume everyone else knows exactly what is going on with everything, but the reality is that most people only understand a small section of the technology we work with. Admitting ignorance can actually empower others: I know it makes me feel better.
As a junior developer, I often face difficulty when trying to keep up with more senior coworkers. When I am pair programming with a more experienced developer, I tend to insist on “driving.” This helps me control the pace and forces my partner to explain what they’re doing as we write our code together. I sometimes feel bad asking a ton of questions to gather more knowledge and context, but that is exactly what a junior should be doing. And patiently explaining is exactly what a senior should be doing. Remembering that helps relieve some of the imposter syndrome symptoms.
Being close to an answer is not failure, but success. This was a hard lesson to learn. I ask to ensure I am on the right path quite regularly. All software is built by direct or indirect teams. Anyone who thinks otherwise is a 10x’r and should be backed away from slowly.
One thing I love about the company I joined is that we emphasize teamwork and unity. Geographically, team members are spread out across two continents, but we invest in hosting several week-long in-person meetups each year. These have been instrumental in building team cohesion and chemistry, as well as giving me opportunities to develop interactive teaching sessions to knowledge share.
I have always tried to set aside my ego and admit when I don’t know something. In fact, after I was chosen for my job, I learned that my refreshing humility was one of the main reasons I was picked. In the last year, I have found that acknowledging my ignorance makes me feel more comfortable and reduces my imposter syndrome. I think my willingness to be honest about what I do and do not know, combined with my eagerness to learn, is one of the things that makes me a valuable employee. I try to stay humble by keeping in mind that there is always more to learn.
A habit I have developed is to write down mistakes and wins in my notes a few times a week. This helps me to learn from my mistakes and combats imposter syndrome. Having a record of my accomplishments also helps me prepare for my bi-annual reviews.
While I adapt to let go of my organizational approach to work, I strive to maintain my organization. It’s as confusing as it sounds. I am finding a balance of organizing logistics and tasks in a way which fits with an agile and ever-changing workflow.
I aim to keep up to date on best practices to continually stay abreast with the industry standards. The job is to learn...which in itself is difficult to learn. I sometimes feel guilty about learning on the job, but I just have to remember, that is the job.
I aspire to be well-rounded. Rather than become a specialist in one narrow field, or a generalist with no area of expertise, I aim to develop what can be called a T-shaped skillset. I am not yet sure what the depth of that “T” will be for me, but I am enjoying the journey toward discovering that.
A thing that keeps me on track is focusing on the value I bring to the company. In the last year I have learned new ways to gauge my own worth. The company that I work for happens to be a lovely place that is staffed entirely of friendly and helpful people, but at the end of the day, a company is a company. The value I bring to that company constitutes my worth. This has served as a guiding principle for me when deciding where to focus my time and effort. For example, if I would like to make a feature that I think is interesting, but no one asked for it and no one wants it, then I am not adding value to the company. I would rather spend my energy contributing to a larger purpose.
It has been hard for me to get in the habit of taking breaks, but nevertheless, I have found it to be immensely helpful. Overworking myself does no one any favors. It is better for both myself and my team to have a short day and then recuperate, rather than to power through the work day while feeling scatterbrained. Knowing this doesn’t always stop me from doing it, but I still try my best to work smarter, not harder.
Burnout is real! Although I strive to maintain a workout routine and schedule plenty of physical activity outside of work, I frequently fail to stick to my goals. Attempting to balance my leisure activities with work has been an ongoing struggle. It is a work in progress that I hope to improve in my second year.
Many of my learning opportunities over the last year came from extra duties that I took on at work. In my company, I became the unofficial advocate for git etiquette in our development workflow. I also became the main driver to consider implementing accessibility features into our products. I never specifically intended for this to become “my thing” and I do worry about being pigeonholed into one particular role rather than growing in different directions. However, it is nice to have my own niche and to develop areas of expertise.
One of the coolest opportunities has been to work on an open source project as a maintainer. Even if it weren’t part of my official job duties, I would still want to be involved in open source projects. I am passionate about making open source projects accessible to newcomers and have put a lot of work into making our project’s structure and documentation more approachable. This interest of mine culminated in our participation in Hacktoberfest, which was quite a huge undertaking. Just now I am applying to Google Summer of Code, and I have high hopes for that process turning out well.
I have made a specific effort to learn in public through blogging and public speaking. I try to write down what I learn and share it with others to spread the knowledge. It may feel obvious, but because it helped me, surely it can help others. I spent a large chunk of my first year’s free time writing articles and developing talks to present at meetups and conferences.
I have also benefited from getting more personally involved in the tech community. Networking with others in the tech industry has exposed me to a huge range of learning opportunities. I have been a mentor as well as a mentee; both experiences have been invaluable in my education.
The great thing about this career compared to others in my past is that it is no longer about clocking in/tolerating the work/clocking out. In this job, I am actually engaged and invested in the work. I now have the freedom to go above and beyond the bare minimum expectations set for me by others. I work on projects that actually make sense to me. My company has a mission that actually speaks to me—I could even go so far as to say it inspires me. Coding and software engineering are brand new to me, yet somehow the work itself seems to fit me better than anything else I’ve tried. I feel that I have been given the chance to independently craft my own career, rather than simply just doing whatever work my boss orders me to do. In the old days, work was a chore that made me feel exploited; over the last year, I’ve learned what it feels like to have a job that gives me a sense of success and personal achievement.