Stick around in this industry and you realize that once you pick a "community", it is quite small. At my current position with Ziff Davis Shopping my manager is someone who I formally mentored for almost a year back in the mid 2010's. I really enjoyed sharing my experiences with him (and another person who became a good friend I never get to see often enough) as we talked about career goals and how to make that transition from "programming as a job" to "programming as a career".

As I am in my early days of being a Staff Software Engineer, a big part of the position is a leadership one. Not only am I supposed to be turning business requirements (and infrastructure requirements) into code, the decisions I make and the patterns I choose trickle down to the rest of the team.

Now it may surprise people who have been lulled by my very effective marketing that the so-called Grumpy Programmer always has lots and lots of time to give to other programmers who want to learn things and discuss my work, their work, and how it might fit together.

Since I do enjoy repeatable patterns, here are some things I think are both repeatable and can lead to success.

If You Can't Explain It, Don't Use It

This is generally good advice for people who want to start giving talks at conferences (come to Chicago at the end of April and see me talk about CQRS and how to configure NeoVim to be a PHP IDE at php[tek] 2024) and even more important in the workplace.

This is why I try and lean on using established software development patterns and working as close to the conventions the tools I am using are expecting. Again, life is too short to fight your software.

Work really hard to only use solutions you can teach other people to use. I feel like my personal strategy of "small units of code, following an explainable structure, snapped together like LEGO" is one I can easily explain.

Stop Assuming Everyone Knows What You Do

This can be hard to do without coming across as condescending or ignorant but it is critical. "I am using the Repository pattern to create some classes to talk to the database? Have you used it before?" is a great example of how to handle it.

I learn something new almost every day from my colleagues, no matter their levels of experience or perceived skill. I have also found the great side effect of allowing me to embrace the idea of "what you are doing is complicated and I don't quite understand it.".

Just because I am a "staff engineer" doesn't mean I understand everything. I understand enough to prototype and make spikes and then dig deeper for answers. Never confuse someone not knowing something with them not being good at their job. I certainly wasn't formally taught design patterns when I entered the industry in the late 1990's.

Embrace Teaching

Pair with people. Seek feedback on your work. Submit work-in-progress draft pull requests. Emphasize the parts of your work you are not sure about. Reiterate the parts that have been successful for others.

I also highly encourage you to embrace the idea of "be the type of co-worker or leader that you wish you'd had early in your career". I didn't have anyone mentoring me, so I stumbled around making a lot of mistakes while ignoring early advice from people that they saw leadership qualities in me (I have a whole talk ready to go about this if you're ever interested in having me do a keynote).

Take Pride In Helping

Look, I know the phrase servant leadership is trendy but the message it it's roots is that as a leader, your job is to serve the needs of the group you are leading. If you look at it from the angle of mentoring, your job is to help the people you mentoring get better. Heck, I try and help people to become better than me.

You never know when you might need help and it's good to know you've created a network of goodwill around yourself.

Takeaways

After reading this you should learn:

• I have mentored people in the past
• I have enjoyed watching them grow into successful careers
• teaching is something I find enjoyable
• take pride in having helped people