If you're reading this, you probably got the link from my resume somewhere. Or maybe I provided it to you somehow. Either way, this README will hopefully do a better job than my resume at answering the following questions:
Either that, or you're just sick of reading conventional resumes.
Follow me as I ponder the question... What if (you're working with Ben)?
Let's start with the why.
I think the best way to describe my love for software engineering - and I'm not trying to be corny here - is that building software is a super easy and accessible way to make people happy. I personally have never seen another profession that is as lucky as us; we get to type stuff up on a keyboard and within a day come up with a little tool that can delight people. For example: I wrote the initial version of a Discord bot that keeps track of people's grocery list within a day, and my family (and apparently 100-ish other people) is still using it to this day.
Oh, and the money; being paid top dollars to sit on a chair all day to type is pretty sweet (and anyone telling you otherwise is a liar or hates their job). As Q from James Bond said:
...I can do more damage on my laptop sitting in my pajamas before my first cup of earl grey than you (James Bond) can do in a year in the field.
Because questions on how to set one up for success is overrated.
I thrive on trust, and I treat everyone as if they are my business partners, even my managers. I have to be in a team that trusts me - or is at least capable of trust - and that I trust with all my heart, or I will quickly crumble like a soggy cookie. A lack of trust can easily demoralise me and it will clearly reflect on my work and performance.
Note the line "capable of trust"; I understand that trust is built over time, not given, so it is especially important for me that the team is capable of trust. This is easier said than done; I've seen teams say "we trust each other", yet treat everyone (even the CEO) as adversaries.
Here's a simple baseline: if you're working on a project with other people, and you have to take a sudden long leave, do you think your team members can complete the project successfully? What if the project has a tight deadline? What if you're the only one that knows how to do it?
I thrive when working in an environment which has the drive for excellence in their DNA. Accepting mediocrity or saying "It is just the way it is" is not a behaviour I would like to be around often.
To clarify: when I talk about excellence, I do not mean obsessing over results; I mean you and the team have to obsess in being able to achieve excellence. A mantra that I hold closely to my heart is that we can choose how we behave, not the results we produce, so as long as we behave in a way that is consistent with "let's make sure that we can achieve excellence", then I am keen to be in your team.
This also means that you have to be able to think big. I hate small businesses who call themselves startups; just because you're small doesn't mean you'll become big one day. You have to be playing to continuously win, not just playing to win in a small pond.
I'm a team-player, and I will always prioritise the success of my team over my own. If my team is successful, then I am successful. I truly believe that making an impact in the world isn't usually a journey one can take alone. A team allows you to tackle bigger problems than you can alone, so having a well-oiled and high-functioning team is key to solving some of the hardest problems out there. Even if I do really well and my team doesn't, I wouldn't feel like I'm winning.
So yeah, I really place a high-level of importance in making sure that the team can function like a well-oiled machine. After all, "people engineering" is just software engineering - except you have to deal with super-complex machines called people.
I think of software engineering as a means to an end: making great products. Engineers are often portrayed as these "nerds" who delight in making their programs run faster. For me, as long as the stuff I build are fast enough that it doesn't hinder the user experience (or developer experience - I should write about that soon), then I find it wasteful to only focus on one facet of the overall user experience.
I think it really helps that I've been privileged enough to be in a non-tech leadership role leading two businesses: as a "CEO" in a now-defunct coffee roastery, and an advisor to the CEO/shareholder of a gloves manufacturer. I've seen how inattention to the overall business goals (e.g. making money, resolving priority conflicts) and tunnel-visioning to "period goals" (e.g. social media impressions) limited individuals' performance. For example, I had to deal directly with the director of a company who was too intimidated to communicate with the contractors he was supposed to oversee, and was instead too focused on his teams' performance.
The year was 2017 and it was nearing the end of my internship; I was finishing up a few tasks and I stumbled upon a security issue of JWTs (i.e. your digital access pass to access apps and such) not being validated properly by one of our microservices.
"Ah, it'll be fine. This microservice isn't used by anyone."