Hello! I'm Rick and I currently reside in Las Vegas, NV. I grew up bodysurfing in Hawaii and gave up a lucrative career in shell-harvesting to learn about 0's and 1's in the forests of Oregon. I worked in IT and software for a long time, eventually making it back to Hawaii, but as it turns out in these hard times, shells don't pay the bills the way they once did. So I co-founded a couple of ventures that taught me a few things about what to do, a lot about what not to do, and I was left wanting to get back into development full-time. I packed my bags, traced my family roots back to NYC, and developed my Rails chops working and consulting with various startups in the city. When covid hit, I relocated back to Tucson to be closer to family and recently hopped up to Vegas.
An iota about my tech roots. Early on in high school, some older friends of mine started an "internet company." This was back in '96 when you could be both an ISP and a web shop at the same time and no one would look at you funny for it. Instead, they'd look at you funny because you did things with computers. My internet company friends mentored me in programming and networking, leading me to head to college for Computer Science. After college, I spent a decade building a career in IT, starting at help desk and working my way into IT and Product management, hitting just about every role in-between. At one point I learned a bunch of math and played poker for a living. I later refocused on software development, leaning into the independent contributor role that I now enjoy full-time.
I enjoy hiking, cooking, dancing, traveling, volunteering and participating in meditation retreats, and bodysurfing from time to time. I ocasssionally live/work out of my 4x4 rig way out in BFE.
My personal mission is to steer towards joy by following deep wisdom.
Professionally, my mission is to lean into challenging business problems, forge the path for the rest of the team, and mentor/be mentored along the way. My role is to empathize with and understand customer and stakeholder pain points, translate those into technical stories, chop those stories into thin slices, and ensure that members of my team, including myself, are able to get product shipped. In doing so, we create exceptional experiences for the end-user. If product isn't getting shipped, it's my responsibility to hop in and help our teams route around whatever obstacle is preventing us from delivering value to our customers.
- Patience allows everyone in the room the chance to have a voice
- Compassion leads to trust, understanding, and joy
- Humor keeps it from getting old, and helps when the going gets rough
- Accountability I do what I say and I say what I do
- Humility comes from knowing that everyone makes mistakes
- Writing self-documenting code - Too often I've gone back to old code I've written and wondered what the heck I was trying to do in the first place. What I've learned is that if I assume I'll forget everything in a month, the quality of the code goes way up. Expect to see a ton of obvious statements -- these are handholds to grab onto later when things start to get confusing.
- Giving others a platform on which to speak - I enjoy hearing what others have to say, and I work to build an inclusive environment that gives everyone, introvert or not, a chance to share their views on the topic at hand.
- Facilitating challenging conversations - When there's an elephant in the room, I search for a way to introduce it, gently if need be, with the aim of shining light on hidden gold.
What consulting has taught me is this -- the right way to code is the way that the team can accept. If the team is offering heavy resistance to a particular piece of code, it's probably not the right solution, and it's a good idea to do some pairing to find a happy medium. It could be that the solution is too conplex, too confusing, is over-engineered, under-engineered, full of holes, or there's simply a lack of communication within the team. Regardless, merging code to fix a team issue is rarely the right response. Stopping to listen to concerns has served me well.
When I'm writing code, I aim for clean, tested, composable, reusable code. The first time through, I'll generally add an if statement. The second time through, I'll work towards a better abstraction and leave some notes. On the third pass, that abstraction gets pulled out and the code gets refactored. Generally, I find this to be the right time to refactor, and unless the business is going to fail if this doesn't ship today, this is when we pay back the interest on the technical debt.
As far as Object-orientedness goes, I find myself time and time again leaning into Sandi Metz's 4 rules:
- Classes should be no longer than 100 lines.
- Functions should be no longer than 5 lines.
- Functions should have no more than 4 arguments.
- A single object is exposed across an endpoint, or between a controller and view.
I like to test things, a lot.
When we're pairing, anything goes, so long as we're on the same page. If you think we're not on the same page, let me know! I'd rather that we take the time to establish a shared headspace, rather than take turns playing follow-the-leader.
- Kinesthetic - I often to rely on feeling out a solution, rather than visualizing it. What this means is that I'll often want to hop into code or project-board land, rather than hash ideas back and forth endlessly.
- Pull notifications - I'm not the type of person who enjoys push notifications. I check email a couple of times a day, I'll check Slack from time to time, but if it's after-hours, I ask that you call or text me if something's up. I'm not ignoring you; I'm protecting my own sanity.
- Flow state - When I do manage to get into flow-state, I may not check email/Slack for hours on end. If something's on fire and I need to know, please send a strong notification.
- Long periods of silence before responding - I choose my words carefully. If it seems like I'm thinking about something, you're right! That's exactly what I'm doing. My ask is that you give me a moment or two to come back to you with a response.
- Timeliness - I make an effort to be on-time for meetings, and expect the same from others. If you're late to a meeting that I'm running, odds are that it started at the time we agreed to start. My ask is that you send a ping out if you expect to be late, that way we can work to adjust our agreed starting time.
-
Initiative is a rare thing, and I want to respect and foster it as much as possible. When I offer a code review, the way I think about it is this: you took the initiative to write the code I'm looking at, and so my role is to help you stay afloat by offering constructive suggestions. Take what works for you, and forget about the rest. If you need support, I'm here to help rubber-duck things that don't make sense.
-
Confusion is common, and is completely OK. It's possible that I'm confused over something, and might offer a non-constructive piece of feedback. If something doesn't make sense to you, let me know -- I'll be the first to admit that I miss a good number of the shots I take. On the same note, if you're confused about something in the code, leave a note and let's work together to find a way through to the other side.
I'm a feedback junkie, believing strongly that feedback is a gift. If you care enough to give me some, I'll gladly listen to it, regardless of content.
There's no such thing in my mind as positive or negative feedback, there's only how something I did impacted you and made you feel. If I did something that angered you, I welcome you to bring it up with me. Likewise, please share any feedback around things I've done that you appreciated so I can get a better sense of where to aim in the future.
I hear feedback best when the data and judgements are separated, and the data is presented first. This helps me identify the context, so that I can better understand the impact my actions may have had on you.
Good: "You pushed all the buttons in the elevator on the way down and then jumped out before the doors closed. You're a jerk!" ("jerk" is the judgement, shared after the data)
Bad: "You should have checked with me before you merged that PR. I have an outstanding branch conflict that will take extra time to resolve, given the order that things were merged in, and there is a way to handle this that will result in less time expended for the both of us." ("you should have..." is a judgement, not data)
On the rare occassion that you might think it a good idea to buy me a thing, instead please consider donating to the Nature Conservancy's mission of Planting a Billion Trees. I send out my fair share of hot air, and any help balancing that is greatly appreciated.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent