Improving

I really enjoy software engineering and am constantly trying to improve. I love being in tech because there is so much to learn and so many problems to solve. Every day I try to be a better engineer than the day before. Here are some areas I try to improve on and topics I've learned over the course of my career that I believe are worth sharing.

An image of a woman learning

Opportunities to Make Mistakes

I'm not sure I can say it any better - take it from ThePrimeagen:

I agree with his point. Improving as a developer means developing a solution, realizing it's the incorrect one, and getting the opportunity to do it again and again and again. I feel as though the industry is incorrectly against "rewriting x feature every n timeframe". Although I understand how wasteful that can seem on the surface, if you're rewriting it for valid reasons, I don't think it's wasteful at all. In fact, quite the opposite.

Obviously if you are having to rewrite it because the organization keeps firing the team that's supposed to maintain it, that's a different story. But if the original group who keeps rewriting it is coming up with better ways of writing that feature, it likely means there will be other positive impacts as well. Maybe those improvements mean cost savings, better performance, or any other increased/positive metric. If rewriting something comes with a net gain, it should be embraced. Okay, back on topic, Tony.

All that to say: it's super important to be given the space and time to make mistakes. The first solution you land on may not be correct or as great as you were hoping. That's okay! Hopefully you'll have time to improve it. Maybe you won't, but maybe you'll experience a similar problem at another company in the future. As long as you learn from that experience going forward, you'll come out ahead.

To organization leaders out there: Don't fail fast, fall fast and get back up. Encourage risk taking. Encourage trying. If you don't read the rest of this article, I encourage you to watch this video from Simon Sinek.

Unknowns and Being Uncomfortable

It can be very scary to take on the unknown, but where there are unknowns, there are opportunities to learn and grow. Rather than being afraid of taking on a task you have no idea how you'd solve, be confident in your abilities and try it. At a minimum, you'll walk away learning something new.

It can feel very uncomfortable taking on something you know nothing about.

"Why would I attempt to create a new GraphQL mutation when I know nothing about how this service works?"

Valid question. But if you complete it, you'll know how to add a new mutation in GraphQL and have a better understanding of work in a backend service. You may also come to the realization that you love writing service code rather than frontend code. That could completely change your career trajectory, all from taking a stab at a single task.

It's good to get out of your comfort zone now and then to stretch your wings and challenge yourself. You may learn more about yourself too!

Learn to Accept "Negative" Feedback

Earlier in my career as I started working closer with designers on a day-to-day basis, I realized they have a superpower that developers tend to lack: receiving criticism of their work and not taking it personally. I was working with a designer friend on a new project when he pitched his designs to a few others at the company. In my eyes, the others were somewhat brutal with their feedback. I was shocked at how calm and engaged he was chatting with his colleagues about his work, right after he took a bit of a beating. He was asking clarifying questions on how the design could be improved, jotting down notes, and acting as though this was normal. How foreign to me as a developer! He just spent a full day working through the designs to be told they were all wrong and not good. And yet, it didn't bother him? How is this possible!?

I asked him how that made him feel and if that type of feedback loop was normal. I was surprised to learn that, at least according to him, yes it was normal. He then explained how it makes him a better designer and how he looks at it as just that: feedback. He gets to decide what he changes or not by taking in all of the feedback, processing it, and coming up with a different solution that he thinks is better. It goes back to the fall fast mentality above. From that day forward, I looked at feedback of my work in a completely different light by removing the personal factor from the feedback process.

Most developers can probably relate: getting Pull Request feedback can really suck. But it doesn't have to. I know for me personally, prior to the point mentioned above, receiving feedback on something I spent days on and being told "this is all wrong" was a very difficult pill to swallow. It's not a reflection on you as a person though - it just so happens that you didn't consider all of these other things your colleagues have thought of.

Imagine working in a factory building parts that have extremely tight tolerances. There's very little room for error when you're manufacturing these particular parts. If at the end of the day, someone reviews the parts you've created and throws out the ones that weren't in spec, would you be upset and take it personally? Probably not. It should be a mutual understanding that the items created must be within spec. Some items you made weren't within spec, some were. It may drive you to do better the next day. So why do we, as software engineers take things so personally on Pull Request reviews?

Instead of receiving feedback and taking it personally, look at it as a chance to improve. Ask questions. Learn more as to why someone thinks their suggestion is better. Have you considered that maybe you are wrong? Being open minded and not carrying an ego goes an extremely long way. Have a civil debate back and forth on topics you may not agree with so that you can understand the counter-arguments and then come to a path forward with your team. Additionally, being able to change your opinions on a topic as new information comes in is extremely important.

All of this is about learning and becoming a better engineer. Obviously when you're giving feedback, you shouldn't be an asshole - that's not what I'm saying. My point is to frame the feedback loop as a positive learning experience rather than one you dread. If every time you put up a Pull Request you feel anxious - ask yourself why? It's not a personal reflection of you as a human being - it's simply the work you output for the job you are paid to do. There's always room for improvement and that's okay. It's all about growing.

People Problems

I was interviewing a candidate when I worked at Toyota in 2017 and I heard a response that has stuck with me to this day:

"People problems" are harder than the technical problems.

What a thought provoking statement. Sure, figuring out solutions to technical problems can be challenging, but have you tried leading a project with completely different individuals towards a goal, accomplishing it in a reasonable amount of time and at a high quality bar, while also attempting to grow the team, while also not driving each other insane? It's so hard. Everyone has different needs. Some folks are stronger in particular areas than others. Sometimes folks don't get along at all.

This is where I have a ton of respect for places that focus on culture fit rather than technical ability. The teams I enjoyed working with the most were the ones where we all got along and had a good time, rather than the teams that were full of rockstars and none of us liked each other. There's definitely an art to team building.

But even if you are on a team where you don't agree with someone, I go back to what I said above about feedback. Learn from those people and understand their view points. Maybe you think they are overly picky in Pull Request reviews - why are they that way? Are their opinions valid? Maybe it's boils down to a personality difference.

From my experience when I encountered people like this, it turned out they really did know what they were talking about. It offered me a lot to learn - it turned out that their communication style was more direct and different than mine. I was taking their feedback too personally. As I got to learn more about them and what drives them, I realized they actually were really nice human beings that did really high quality work. I also learned a ton from them. I recommend trying your best to solve "people problems" as well as the technical problems.

Learn to gel with the folks you work with. Work doesn't have to be a slog - we're all human and crave connection to some degree. Working in a team is all about alignment and driving towards a common goal. Find ways to make work more enjoyable. You may gain some lifelong friends!

Lastly, I recently participated in a DiSC assessment with my team. As most developers likely would, I was thinking: "I'm not sure this is going to be a good use of my time"; however, I walked away thinking the exact opposite. It was extremely helpful. Learning the stressors and motivators of your teammates goes a long way. Maybe large ambiguous tasks make one person extremely anxious, while for another those tasks are where they excel. Doing this assessment helps outline where folks fall in different categories so that you can work better as a team. This type of assessment is a bit of a catalyst to what I described above - you get to learn more about your team much faster than the more organic process and get to cut down on "people problems".

Learn to Say No & Protect Your Time

It's super important to ensure your mental and physical health is taken care of before anything else. Without being in a good mental and physical state, you won't be you (is this a Snickers commercial?). One recommendation I received is to say "no" more. It's important to protect your time. If you're in the position where you can decline something, and you think it'll tip you over the edge, just say no. There are obviously more professional ways to politely decline things as well.

Even simple things like someone scheduling a meeting outside of your working hours. It's appropriate to decline and say something along the lines of "is there a chance we could move this between 7am-3pm?". Or simply decline and suggest a time block that works better for you. This is one of those tips that doesn't get talked about enough in the workplace. Obviously there may be some cases where very important meetings need to fall outside of your typical schedule; however, don't be afraid to protect your time when you feel it is appropriate to.

Struggle a Little

There is absolutely nothing wrong with asking for help, but sometimes struggling with the issue for a few more hours could mean you get to the bottom of it. If you're on a time crunch and there's a fire in production that you're on the hook for - you should ask for help immediately. But if there isn't an extreme urgency, there's an opportunity for you to dig deeper on the problem. It goes back to above on being uncomfortable - not understanding why something isn't working as you'd expect is an uncomfortable feeling, but taking a step back and evaluating what could be going wrong, then digging in to see if your hypotheses are correct means more opportunities for learning and growth.

One of the patterns I was taught early on in my career was to dig through stack traces and attempt to figure out the root cause of the issue. You learn a ton by doing this and you get exposed to things you may not otherwise see. It also sharpens your troubleshooting skills. Sometimes you may find a legit bug in a library - this means an opportunity to contribute back to an open source project in a meaningful way. Other times you may hit a dead end - that's okay! You made a great attempt.

One tactic I use is going for a walk or stepping away from the problem. Continuing something for multiple hours straight and not making any progress can lead to a dead end, but sometimes an idea will come to you out of the blue if you step away for a bit. For me, my best ideas come about when I'm by myself doing a mundune task like driving or doing yard work. Give yourself a break for a moment and see if any new ideas come to mind.

When you do end up asking for help, it's important to describe the problem and also show everything you've tried. That will give whoever is pairing with you an idea of what you've thought through and tested already. Maybe it'll give them some clues as well. It also shows that you respect your coworker's time by letting them know you really are stuck. Asking for help isn't a bad thing, but it's important to feel a little uncomfortable at times to see if you can figure it out before phoning a friend.

Publish and Maintain a Package

Now onto a more technical suggestion…

If you're abstracted away from a lot of concepts at your workplace, try spinning up a side project or get on a project at work that is greenfield. I firmly believe every developer should create a new package from scratch, publish it to npm, and maintain it for some period of time. Being able to create packages on GitHub, build them, publish them to npm, setting up testing, linting, prettier, and general repository maintenance is one way to learn a lot of skills that are extremely applicable to your job in a short amount of time. It really levels you up fairly quickly.

From a high level, doing this means you'll:

  • Learn the different fields in a package.json and what they do
  • Add tooling to build your packages
  • Setup a test framework
  • Setup GitHub Actions
  • Wire up tests
  • Update your GitHub Actions workflow to include running your tests
  • Setup up ESLint and prettier from scratch
  • Publish to npm
  • Write documentation on how folks use your work
  • Setup TypeScript configurations (if using TS)

All of above takes a lot of effort, but you'll walk away knowing so much more. The experience you get setting up these tools for the first time is well worth it. You'll also appreciate the tooling that is abstracted away from you at larger organizations, because you'll have a better understanding of what all is going on. Not only will you learn a bunch by doing this, it's also fun to do!

That's All I Got

These are the things I've done to improve as a software engineer over the years. I hope this is helpful for others. Let me know on LinkedIn or Bluesky!