ARTS - Week 5

Let's ROLL!

Algorithm: Product of Array Except Self
Review: How to Guide a Meeting as Software Engineer
Tips: Something about dbt-osmosis
Share: About Writing my Working Guideline

Algorithm: Product of Array Except Self

// [prefix, current, postfix]

func productExceptSelf(nums []int) []int {
    n := len(nums)
    output := make([]int, n)
    
    prefix := 1
    for idx, num := range nums {
        output[idx] = prefix
        prefix *= num
    }
    postfix := 1
    for idx := n - 1; idx >= 0; idx-- {
        output[idx] *= postfix
        postfix *= nums[idx]
    }
    return output
}

Review: How to Guide a Meeting as Software Engineer

Make the points clear. Keep the meeting effective before(prepare), during(focus&communication) and after(document) the meetings.

Definition of Ineffective Meetings

• Before the meeting: doubt their existence and the necessity of the meeting

• During the meeting: confused about the goal and why

• After the meeting: unclear conclusion and decision

Before the meeting: preparing for the goal

It’s helpful to send clear message in group DM or channel for preparation

1. Know the goal and outcome, and invite right people to attend.

1. Ensure people know why they’re invited with some meeting description(e.g. purpose of the meeting and goal of it)

1. (With BLUF)Give clear tips if we need people get prepared(e.g. design doc)

During the meeting: leading it successfully

1. Align everyone on the expected outcome of the meeting with the words “By the end“.

   1. “Hi everyone, thanks for joining. The goal of this meeting is to align on the North Star vision for the front-end team. By the end, we should agree on the high-level objectives for the team and a roadmap order of what should be worked on. Before we begin, does anyone have any questions?”

2. Keep the topic on track toward achieving the outcome with some time limit(like 1 minute) if the talk goes off.

   1. “These are great points. For time purposes, I’d like to bring us back to { previous, on-track point } though. Is it ok to take this offline?” Sometimes I may add, “I can help coordinate the follow-up.”

3. Ensure everyone feels heard. No one likes to be in a meeting where it feels like their opinion wasn’t heard.

   1. Ask silent people for their opinions.

   2. Thank points brought up: “That’s a great point. Let’s dive into that more.”

   3. Add pause points. “Does anyone have concerns with this approach?”

4. In the last 5 minutes, try to start wrapping up the discussion and cover any action items.

After the meeting: follow up

1. Document all important points: vital points discussed during the meeting, and organize them after.

2. Call out actions items, post a link to meeting notes and a specific section for action items with assinees.

Ref

• Guide to leading meetings as a software engineer

• https://www.animalz.co/blog/bottom-line-up-front

• https://www.weskao.com/blog/how-to-regain-control-in-a-meeting

Tips: Something about dbt-osmosis

Primary purpose of dbt-osmosis is to automatically generate and manage YAML files for your dbt models. We opt for explicitness over implicitness.

dbt-osmosis is a tool my company current uses to automatically generate yaml file for dbt models. In my opinion, it’s a waste of time to manually fill the yaml file to annotate the column information. To some extent, this file could save lots of time, and easy to validate the table with lots of columns.

FYI, our frequently used command is:

dbt-osmosis yaml refactor --numeric-precision --char-length

For my understanding, dbt-osmosis tries to read the information from actual models(generated by dbt build/run), and update the columns information, even in source.yml as long as we configure it well .

Share: About Writing my Working Guideline

I just wrote an article “Working with Oscar: An unauthorized Guide” about how I usually work, even though I copy and paste from the origin article a lot.

I indeed learn a lot from it through reviewing myself:

• What kind of work style I am comfortable with

• The shortage of myself, i.e. overthinking, talking away from the focus

• How much I like communication

• etc.

It is a good practice to know myself from work. I would say it’s totally a different thing from the normal self-reflection even though they have lots of similar points.

Ref

• https://assets.ctfassets.net/fzn2n1nzq965/6bKUeQ36CwyDoAUKC965tv/599e5b5a42bb970abbdba03c9ae87578/SCAPE_Working-With.pdf