Monthly Archives: August 2022

[kcdc 2022] 4 deadly sins of mentorship

Posted on by
Reply

Speaker: Christina Aldan @luckygirliegirl

For more, see the table of contents

Notes

  • “Experiences re the sum total of who we are, but not of what we can become” – Christina’s first mentor
  • Pass on experience
  • Doesn’t need to be older, just needs to have an experience to share
  • Results legaycc, relevancy, avoiding mistakes, honest feebck, long lasting friendship, employee retention, strenthen teams
  • Teach: work experience, new hires, resource suggestions, skill building, networking tips, how to give/receive feedback
  • Helps mentor – stay relevant, emotional intelligence, expand network, reinforce skills, is fulfilling
  • Idea: mentor monday’s – start on happy note
  • Helps mentee – gain practical advice, emotional intellingence, expand network, improve communication, get direction/focus
  • Mentoring is not making a copy of yourself. Learn from a variety of diverse people and pick what relevant to you.

Arranging mentoring

  • Can be any duration. ex: coffee once a quarter
  • Can reach out to someone you follow online and ask to discuss experience.
  • 7 minutes is a specific time limit. 5 minutes sounds like an owner. will probably renew another time
  • https://www.polywork.com has less noise than linked in
  • Measurable, finiite, clear on want help with, mentor knows that that mentor,
  • Ok to be ongoing if still set goals and be intentional.

Emotional Intelligence

  • Awareness of self – needed for empathy. Improve by naming emotions more specificallly
  • Management of self
  • Awareness of others
  • Management of others
  • Neuroplasticity – can make new connections. As soon as 5-6 hours after create new response, starts. More stimulate, the stronger the connection becomes. (thicker/more connections). If don’t stimulate neuropathway, it disolves

Sins

  • Using guilt or shame
  • Not dictatorship
  • Motivating with bribes
  • Courtesy bias – don’t want to hurt feelings. However, growth happens in discomfort

More notes

  • Tech, don’t preach
  • Guide through process
  • Mentee needs to internalize
  • Be a talent detectve to see what the mentee wants
  • Be honest while remaining kind
  • Host open hours, inlude in contractor fee, cross-dept, panel mentoring, join another team one day a month to see what do (job shadow)
  • Define boundaries, identify an dassign mentor, set a timeline
  • If no goal/end date, just fade away. Mentee wonders what’s up and mentor thinks all is fine. Reach out
  • Mentor fatigue – be aware of what you can offer. Needs to be sustainable
  • Mentee should be concise, engaged and proactive
  • Mentor – stay in lane (only there to share experiences, not a parent/therapist) set clear hours, comunicate clearly

ALGEE (for mental health)

  • Access
  • Listen
  • Give Reassurance
  • Encourage Self Care
  • Encourage professional help

My take

Christina began with a great story. I like that she did it before introducing ourself. It results in a stronger audience connection and is something I’m trying to get better about. The content was excellent and relatable. She made it interactive so we got to hear a bunch of experiences. My only complaint is the room was too small for the audience. The captioning was A LOT (10 minutes?) behind. It started late so don’t think anyone was relying on it though.

[kcdc 2022] network fundamentals for developers

Posted on by
Reply

Speaker: Sean Whitesell @codewithseanw

For more, see the table of contents

Home networking

  • Lots of devices at home
  • Some devices require connectivity to phone home or won’t operate
  • Home devices connect to router
  • LAN – router <–> home devices
  • WAN – router <–> internet
  • Local devices not having IP exposed to world
  • Packets – pieces of data – think of as train cars. Don’t put everyone in same car

DNS (Domain Name Service)

  • Converts friendly name to address. Like calling a contact – you don’t know the phone number
  • On Windows:
    • ipconfig /displaydns
    • ipconfig /flushdns
  • A record – name to IP
  • CNAME – alias – subdomain www.google.com points to google.com. Can route to elsewhere
  • MX – mail exchange
  • nslookup set type=NS (or MX or CNAME or AAAA for IPv6)
  • nslookup url.com – can return multiple addresses so resiliency if goes down

Routing

  • If mail a letter, look at zip code then street than address.
  • Like a perimeter. Routing brings inside house
  • IP v4 – 32 bits
  • Subnet mask 255.255.255.0
  • Class A – 0.0.0.0 – 127.255.255.255 – 128 networks, 16 million addresses
  • Class B – 128.0.0.0 – 191.255.255.255 – 65K addresses
  • Class C – 192.0.0.0 – 255.255.255.255 – 254 addresses
  • RFC 1918 – non routable addresses
  • CIDR (classless inter-domain routing) notation lets you waste less addresses – ex: 10/8

Network sizing

  • If don’t pick enough have to move all devices
  • 10.0.0.0/24 – CIDR says use first 24 bits – 256 addresses
  • 10.0.0.0/23 – now use first 23 bits – 512 addressesCloud doesn’t let you do /30 because only 4 addresses and AWS/Azure use 5 addresses per subnet
  • Subnets – like multiple rooms in a house. To partition things off

Network Address Translation

  • 192.168.* means internal/non-routable address
  • http://whatismyipaddress.com – shows public address
  • Router keeps track of ports and which device to go to
  • 65536 available ports. 0-1023 are reserved. Similarly browser tabs have ports to keep track of conversation

Common ports

  • FTP – 20 and 21
  • SSH – 22
  • SMTP – 25
  • DNS – 53
  • Web and SSL/TLS, HTTP/HTTPs – 80 and 443
  • SQL server – 1443

OSI (open system interconnect) model

  • 7 – application – Azure App gateway, AWS ALB, Mginx
  • 6 – presentation – SSL
  • 5 – session
  • 4 – transport – TCP (ack everything; very chatty) vs UDP (send and forget without confirmation), Azure LB, AWS NLB
  • 3- network – IP
  • 2 – data
  • 1 – physical

North-South East-West Security Model

  • DMZ
  • App Server Layer
  • Database Layer

Route table

  • Control and enforce traffic
  • Determine which traffic goes to firewall.
  • Different rules for different subnets
  • Private subnet has no internet access
  • AWS has internet gateway – needed to get to internet

Cloud

  • Load balancer – can be layer 4 or 7
  • Network security groups – VM/EC2 level, stateful
  • AWS NACL (network access control list_ stateless. One rule does not allow both directions

My take

This was a good overview. Some I knew. Some I used to know. Some was new. The end felt rushed. Regardless, I’m glad I attended.

[kcdc 2022] lessons from reviewing a very big pull request

Posted on by
Reply

Speaker: Patrick McVeety-Mill @pmcvtm and @loudandabrasive

For more, see the table of contents

PR Principles

PR is to merge code. Typically involves gate checks and review

  • well organized – code resonably grouped, scope is defined and right sized, mostly related changes (not so small that annoying, not so big it is difficult to review. keep side stuff to a minimum)
  • well documented – high level description, story of the approach, issue/ticket/doc reference
  • well considered – planned before opening, open for discussion pragmatic not dogmatic
  • well reviewed – thorough (high and low level), ode efficient and matches style, tested (functionality over all else)
  • have empathy – for author, reviewers, future readers of code, users of product

Context

  • Open source software provider
  • This PR came from a partner – large changes in the past with reasonable success. Semi-rotating cast of devs
  • This change wasn’t made by the same people who learned how to do things first ti
  • Semi-collaborative – weekly syncs, shared chat room
  • Initial plan was for smaller chunks but hard to enforce
  • Doing free work for company because partner
  • Wound up being 900 lines

How approach looking at

  • Accept your fate – mentally prepare
  • Assess the scene
    • look at high evel and plan process
    • web UI doesn’t help with hundreds of files git diff —name-status main gives a list of the files and status. Redirecting to a file gives all of them
    • Dump into a spreadsheet – can sort by change type (add/modify/delete/rename, project or file name)
  • Translate into a checklist – track as go through files. Can do in markdown or Excel. Markdown lets you copy/paste into the response later
  • Look for smells – need to look at closely
    • R100 – means rename an no differences. (100% same.) Can be irectory rename or file name refactoring
    • Add/delete with similar names. Changed a lot.
    • Big chunks of adds – new features
    • ”C” s for copcying a file
    • At this point, leave feedback and ask to rename back to cut down the diff and can restore them in a follow up. This will make PR smaller
    • This got 900 file PR down to a 600 file PR
  • Disappear and review – look at each project/file. add/delete then changes.
    • git difftool -d main MyDir
    • Used BeyondCompare to see visual
    • Looking for critical differences
    • Quicky note format/style issues
    • Manually test related features before moving on
    • Don’t get stuck viewing diffs – want to understand big picture
    • Use diff tool most familiar with so not learning new tool while doing this. Your IDE may have a useful tool
    • If multiple commits, read comments to see journey
    • Use an IDE or tool that can highlight warnings – ex: unused code
    • track and note comments in your checklist
  • Give feedback
    • Be incremental – don’t wait til the end. Give feedback file by file/project by project. Can do in description with multiple posts.
    • Be specific and actionable list files/line numbers, allow author to indicate resolution, explain reasoning where can
    • For small PRs, comment inline during review (ex: GitHub). For super large PRs, crashed tab because so large. Gives top evel coment but reference the specific file names locations.
    • Prioritize with MoSCow – MUST do before merging, SHOULD do or create debt (task for later), COULD do to be nice, WON’T do even i we like (maybe an epic later). Also questions and comments.
    • Indicate nits. Still fix but clear what it is.
    • Compare against your notes to mae sure done
    • Saw ”when” – give tricky issues back to internal team. Can use epic/release branch. Can merge into there so not in main until fix everything.
    • Be diplomatic – remember everyone can see and don’t want to scare contributors away (free work, want to keep)
    • Don’t close PRs without comment

Timing

  • 1 month to merge to feature branch (1-2 weeks for first pass)
  • 2 months to finish all follow up issues

Preventative Measures

  • Formatting
    • pick a format and stick with it
    • setup auto-formatting
    • if strong arm, know it is annoying
    • report early rather than every instance
    • decide how important it is
    • .editorconfig files are cross language and cross-IDE
    • githooks
  • Repository Templates – placeholder text for PRs and issues to show what want
  • Automate checks and report back. Builds are for when code changes. Bots check things as time passes

Communication channels

  • PR interface good for tracking progress, leaving artifacts for others to look at, the original comments from squashing comits
  • PR interface not good for feature details, complex scenarios, brainstorming
  • Use shared issue tracking – just knowing the github issue is in progress for months isn’t helpful. Use a github board or trello
  • Get agreement on what PR will be
  • DIscuss offine and post result
  • Alternatives – Frequent pairing (still do PR at end), periodic review (ex: review monthly ”state of the union on the repo”), trust/testing/recovery (everyone merge to main)

My take

This was fun. It was very information heavy, but easy to follow. And I learned a few new techiques.