[2023 kcdc] rescuing your git repo using amend, reset, revert, rebase, bisect and cherry picking

Posted on by
1

Speaker: Brian Gorman

Twitter @blgorman

Repo with all commands

For more, see the table of contents.

Note: The GitHub repo is excellent and has all the instructions/commands. I did not try to recreate them in my blog. Instead I focused on the concepts

Branching strategies

  • Git Flow – main > dev > feature > developer. Good if just starting out. Not doing a lot of rebasing
  • Trunk based – no long running branches, frequent checkins. More popular due to CICD
  • Forking – integration repo, lieutenants and dictators. Good in super large orgs. More advanced
  • While branching strategy doesn’t matter, does matter if linear commit history. (Some operations are trickier if non-linear)

Rebase and Force Push

  • Rebase locally (based on remote or local branch)
  • Can have orphaned commits
  • Force pushing with a lease makes it safer
  • May have to deal with conflicts on a rebase
  • Use pull request; don’t create an extra merge commit
  • Important to delete old branches to avoid confusion

Finding lost commits

  • Can use GitViz (on WIndows only?) to look at graphically – https://github.com/Readify/GitViz
  • git reflog –all
  • git checkout <id> – puts in detached HEAD state to look at it. See double parens around commit id.

Clear local cache

  • Unlikely to need. Cleans up state
  • git reflog expire –expire-unreachable-now –all – expire all commits now
  • git gc –prune – run garbage collection

Removing feature

  • Not a problem if use feature flags
  • Create a branch to keep safe the parts not changing
  • Reset branch to last commit want to keep
  • Create new feature branch and pick commits want

Accidentally committed to main

  • Stop build as quickly as possible
  • Let team know not to change or pull from main
  • Create feature branch and cherry pick commits want
  • Reset main hard. git push –force-with-lease
  • Revert change to keep history
  • Change settings on repo so can’t commit to main again :).
  • (if can’t do this, can revert instead of changing history)

Someone committed a secret

  • If only a local commit, delete .git and start over. If already pushed…
  • If don’t need history, create new repo without history. If can’t….
  • Stop all dev as doing massive history update
  • Ensure all code checked in
  • Use git bisect to find the first commit containing the secret (start, good id, bad id, then you keep saying if a commit is good/bad). Alternatively git log -S “secret” gives you the commit
  • Ensure no branches are dependent on commit after the last good commit
  • Amend commit with one that doesn’t have the secret, Then cherry pick the rest
  • Everyone has to get the repo again since commits have changed

My take

I really like the mix of concepts, visualizations and videos of actually using the functionality. Great session.

[2023 kcdc] chatgpt: don’t take my job, help me thrive in it

Posted on by
Reply

Speaker: Steve Odell

For more, see the table of contents.

Timeline

  • 1940 – enigma
  • 1964 – first chat bot
  • mid 2022 – GitHub co-pilot came out
  • Then ChatGPT 3.5
  • Panic about AI taking all our jobs

Survey

  • Most people in room used ChatGPT
  • A few used Bard
  • A good number use GitHub Co-Pilot

1969

  • Had ChatGPT write a story about ATMs rendering bank tellers obsolete
  • It was well written
  • Talked about roles evolving
  • Also covered analogy to ChatGPT and talking about enhancing capabilities

Takeaways

  • Not going to take our jobs
  • Can let you down just as much as it impresses you
  • Do not take at face value
  • Often apologizes when wrong and wrong a lot

Examples

  • Lawyer used ChatGPT which made up cases. Used real case numbers but unrelated – https://simonwillison.net/2023/May/27/lawyer-chatgpt/
  • Asked for a C# function to calculate the points in a bridge hand. Gave it the rules in a prompt and a description about the notation. Quickly provided code that looks reasonable on first glance. When tested code, got wrong answer – 18 points, for a 20 point hand. ChaptGPT also wrote a bulleted list explaining logic and got 20 points in explanation, but not code. Realizes messed up and explains why wrong in a way that conflicts with the explanation.
  • Succeeded at codegolf – rewriting code in less lines.
  • Tried to get to write infrastructure as code. First gave approach to set up cloud formation for a high level description of what want for AWS. Did good job listing AWS services need and short description of each. Then asked to create the cloud formation templates listing services. Gave a stub of the yaml leaving out all the hard parts. Ex # VPC properties. Then tried one at a time and didn’t tie them together..
  • On the next example for an OAUTH workflow in Maui, ChatGPT just said can’t do it and provided a basic login page which was nothing like what asked for. Thinks not enough code as training data. New and lot of code is internal to companies.’
  • Repeated example in Reactive Native. Didn’t test, but looks much better; includes OAUTH workflow and expected parts.

Prompt engineering

  • Some companies are hiring prompt engineers
  • Skill set we should all learn
  • Tried getting SQL for a recipe app. Asked for table with create table scripts listing fields want and more about each. Did good job on keys and not null constraints. Unit of measure was vararg rather than numeric. Did right when asked for a units of measure table.
  • Chaining prompts in the same discussion gets to where want.

My take

Standing room only crowd. I got there very early (because I needed to leave at the 30 minute mark) and was barely able to get an aisle seat. [I misread the calendar and have a work presentation at 11am eastern].

The first half of the presentation was excellent. The examples were clear and run. Gave an excellent sense of the current state of AI. The beginnings of the prompt engineering section was great as well. I wish I could have stayed for the rest.

[2023 kcdc] what your product manager actually does & why it matters

Posted on by
Reply

Speaker: Annie Cochran

For more, see the table of contents.

Like the speaker, I”m using PM in this post to mean product manager

Overview

  • Amount of power varies amongst PMs
  • Product Manager vs Product Owner vs Project Manager – these are different roles. Some companies use these terms interchangeably or merge the roles
  • PMs role is to protect developer’s time, unblock things, have conversations/meetings, etc

Day in the life

  • Lots of meetings and prep for a lot of meetings.
  • Common to be double/triple booked
  • 10 meetings/day
  • Juggling between meetings/inbox/to do list
  • Review notes/action items/next day’s schedule

Potential opportunity meeting

  • Frst hear about opportunities to strengthen product.
  • Talk to devs only if agree good opportunity.
  • Say no diplomatically if not.
  • Sometimes not bad but not enough time now.
  • “No and…” – need manager to stand by decisions when need reinforcement
  • Represent team/product at meetings
  • Protect goals of product and team

Brag about the team meeting

  • Celebrate publicly to senior leadership and executives what devs did.

Discovery

  • Series of meetings and activities
  • Trying to discover user needs/goals/pain points
  • Tries to choose best method for the problem at hand
  • Vet work and decide if take back to team
  • Another meeting where protect devs time
  • Use Mural

Other types of meetings

  • One on one – ex: engineering manager
  • Surprise meetings
  • PO meeting
  • Team ceremonies – ex: standup refinement/grooming

Refinement

  • PM fills in where can.
  • Then team fills in. Pre-refinement. Does twice a week for a specific set of stories. A developer must be present because talking about technical details. Investment of time.
  • Actual refinement is after tech lead involved

Shouldn’t do

  • Don’t make technical choices
  • Don’t need to know all tech solutions
  • Not CEO of the product. Don’t want to make decisions in a top down way. Make choices with the team vs hierarchically.
  • Don’t need to control every moment of pre-refinement
  • Tech adjacent, but not technical
  • Not a data analyst. Interpreting data, not collecting it.
  • Not a project manager. Project manager focused on timeline/deadlines (when). Product manager focused on whether should do it at all (why)

How can devs help the PM

  • Participate in meetings.
  • Pay full attention in meetings; don’t do side work
  • Listen so know when can contribute.
  • Give input when asked. Gives confidence for others to share.
  • Prepare in advance when asked
  • Communicate problems as soon as blocked. Give info so can deal fight dragons.
  • Constructive criticism when needed

Product Owner and Product Manager

  • Common for it to be the same person
  • Similar role
  • Internet says PM is more strategic and PO is more tactical
  • Someone in audience said PO supposed to have more authority. Others disagree.
  • Another person said transferred PO to PM
  • Another person said PO helps prioritize backlog as exists, clean it out. BAs groom stories. PMs oversee activities but focus on why.
  • Another person said PMs looking at longer term and POs focus on day to day (ex: standups/impediments)
  • There’s a PO Analyst course role between PO and PM
  • Conclusion – varies a lot by organization and even within an organization

Tech debt

  • Annie is a former dev (for 8 months)
  • Explain why important, robustness, maintainable
  • Make it less abstract
  • Technical education from team so can explain to business. ex: can’t deliver X until fix Y.
  • Don’t ask permission to do job right. Just right tests

My take

This was a fun start to the day. It was nice seeing the POV of a product manager. Annie is a former developer who has been in the role for 13 months. This is a good amount of time for the topic. I like that she crafted a message specifically for developers. I enjoyed both the talk part and question/discussion part. There was a lot of activity.