sungchun12 / README

:scroll: My personal reference for when I meet new teammates. Not something I share willy nilly. Kudos to you if you're reading this on your own!

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Howdy, I'm Sung!

Why read me?

I'm writing this because I was inspired by other readmes to expedite some "get to know me" questions. I prefer face to face, but I know I work with remote teams where we don't get the chance to fully expand on what I'm sharing throughout this document.

I love building great work together when the problem context and my personal working posture align, and I want you to know what I consider alignment.

I am a work in progress just like you. My motto is being "humble and hungry", and I hope you journey with me as we grow together in that.

My role

  • Building solution architecture diagrams, usually around end to end data pipelines
  • Executing on the above with hands-on code
  • Engaging in pre-sales engineering conversations
  • Building code-based starter kits and utilities for my team

What I Believe In

  1. Learning by Building in PUBLIC: I'm a big proponent that hands-on, tangible work reveals skill and growth more than lectures and certifications by themselves. In the past, I would limit myself in thinking academic technical knowledge around a topic equated to being ready to deploy something production worthy on day one. I thought I had to create the same POC everyone creates on their first Medium blog post to show, "Hey, I'm an engineer internet stranger! Validate me!" I don't believe in proxies to being a better engineer without actually working to become a better engineer. Appearances are the not same as being. I'm way more interested in journeying with myself and with you in building meaningful experiences and tools that actually work.

  2. It's not about getting what people usually want, it's about surpassing who I am: It's taken a lot of hard conversations with myself, community, and mentors to awaken a drive to chase after being a growing person rather than prestige, golden handcuffs, and corporate ladders. I strongly advocate for projects/work that grow me into the person I want to become, not what will be bureaucratically advantageous. Titles as an incentive for doing work incongruent with my career vision will not motivate me. I thrive in hands-on work, not powerpoints(see point 1 above).

Accountability

The general thrust of this is: let's agree upon what we need done and why, enable me with resources and knowledge, and check in frequently while I throw myself at it.

  1. Start with Why: I generally believe in articulating the core story underlying the problem we're solving. If it can't be named in plain language, then I can't imagine the end result will resonate with the end user. The upfront work can be cumbersome, and I do see the art in discerning whether we're brainstorming or going into analysis paralysis. However, I like doing my best to avoid building a rocket when we need a boat or worse vice versa.

  2. Frequent, Specific Deliverables: I work best when I know exactly what is expected of me, and you'll notice me repeat next steps back to you. I believe words are precious, and I'll be as honest as possible about when I can deliver something: Wise Words

  3. Stretching my Ultimate Tensile Strength: I thrive in jumping into the deep end, and I love the challenge of building things that haven't been Medium blogged to death. I'm willing to go to the second tab of a Google search to figure things out. That's some due diligence right there.

How I Work

  • How should people set time with you? I prefer slack for conversations that take 2-3 minutes. If it's something 4-10 minutes, let's pickup the phone in real-time. It minimizes a lot of back and forth, and tone and subtext show a bit more. For anything longer I keep my calendar updated regularly, so slap something on a reasonable time window!

  • What's the best way to discuss issues with you? I am open to real-time conversations about work quality and/or interpersonal working dynamics. I welcome you to setup time 1:1 with me and a heads up and/or tap me on the shoulder and ask if we can discuss something in that moment. I ask that you name behaviors and end results from me that you challenge because it'll be something measurable I can act on rather than a nebulous character judgment.

  • How do you define "Done"? I typically list a bunch of internal acceptance criteria and get through 80% of that list before sharing my results with the rest of team. My aim is to show the team I'm pulling my weight but open to feedback and pivoting if I'm missing the mark before I get too emotionally attached to my 100% done definition. Documentation and testing are built into my definition of done but don't expect every edge case under the sun to be accounted for in the first draft. My ethos is that there is no final done, just better and better drafts.

  • When are you available? Chicago timezone. If you want, we can work through: calendly

Personality quirks

  • I tend to go straight to heart to heart, introspective conversations with people when I pickup the sense that you can handle it. Sometimes this may be intense for people, and I'm more than happy to redirect the conversation if the vibe ain't right.

Known Failure Modes

  • I am demotivated when my workload is more about bureacracy and wordsmithing than hands-on development. I specifically notice this trend when you have technical AND social skills. People think you should play project manager/peacemaker and hands-on development double duty. Usually, you end up doing the former because the meetings eat up all your time and everyone loses in that deal.

  • When I know you haven't looked at my work seriously when you specifically requested it, I feel disrespected and will direct my energy to other priorities besides yours. Actual example: I had a team member pester me for weeks to finish a data pipeline. When it was finished, they didn't come back with feedback until months later saying it didn't quite meet their needs. It was clear they didn't look at my work even though they pressed me with urgency.

  • When aggressive tone is used to push a point rather than clear evidence-based logic, I assume you haven't thought your claims through. Typically the, "This new idea just doesn't make sense, let's do this like we've done before." scenario communicates lack of due diligence in trying to make sense of a new idea.

  • I have more, but these are the main ones in this season. More than happy to share more if you ask ;)

Tools I Use

CLICK ME: StackShare

Misc

This idea comes from Manager README's - I'm no manager but I like the idea of READMEs to accelerate getting-to-know-you phases, especially asynchronously.

This is a living document, and I can't wait to show you my new commits along the way :)

About

:scroll: My personal reference for when I meet new teammates. Not something I share willy nilly. Kudos to you if you're reading this on your own!