Book Reviews

Waltzing with Bears – Book Review

Leave a comment

Waltzing with Bears is one of my favorite reads. It has become essential reading for anyone leading projects. It’s honest and pragmatic, providing evidence for the need and power of good risk management for project planning.

Rating

(Higher is better, 5 is neutral)

  • Would I recommend? 10 / 10
  • Did I learn anything? 9 / 10
  • Did I learn anything I can apply? 9 / 10
  • High Information density? 10 / 10
  • Would I re-read? 8/10

Buy Waltzing with Bears on Amazon

Waltzing with Bears Book Cover

Waltzing with Bears Overview

Waltzing with Bears takes us through the journey of Managing Risk on Software Projects. It starts out analyzing what Risk really is and why it matters. Then it transitions into demonstrating what we can do about it, how to talk about it, tools we have, mitigation methods, and common pitfalls. It shows how analysis of risks & their probabilities can inform the probability curve of delivering a project

Ultimately Waltzing with Bears advocates for being open & honest about what on a project we can control, thinking about what risks we can mitigate, and how we can more realistically plan projects while including uncertainty.

Who should read Waltzing with Bears?

Every Project Manager, Product Manager, Head of Engineering, and Senior Engineer. It will shift how you think of projects and give you the tools to stop guessing about projects and start projecting realistic projects.

My main takeaways

Don’t ignore project risks. Risks make us more self aware and not count on ‘luck’ or ‘stars to align by chance’. We can eliminate a good portion of guess work.

We can use math to quantify risk asses its probability of impact on a project delivery dates or outright failure.

Deadlines dates are a bit of a myth. Instead a distribution confidences for completion is more realistic when Planning Projects and Road Maps.

Just because you wish / hope / believe that things will go perfectly, doesn’t mean they will.

If you did no diligence in checking for risks, and a project goes perfectly, you are just as guilty as someone who knew of risk and did nothing about them. See Ethics of Beliefs.

5 most common items that impact software project timelines: Scheduling Flaw (ill informed project timeline), Requirements Inflation (additional unplanned work), Turnover (staff leaving), Specification Breakdown (ignoring agreeing upon what/how key items are built), Under Performance (low/high throughput by team).

Riskology Worksheet is a great way simulate these risks impacts on a project.

If you liked this book, next I’d recommend

On team culture: Debugging Teams

Coding

Batch conversion of SVG to PDF (updated)

Leave a comment

Thanks to Runbgmn for the original instructions on batch conversion of svg to pdf. The instructions there are currently out of date, so here are an updated set of steps I found to batch converting svg to pdf with Inkscape.

Batch conversion of svg to pdf is very helpful. This is how it can be done under Mac OSX for free, no need to buy any software nor upload anything.

The Setup for Batch Conversion of SVG to PDF

  1. Get the free vector graphics program Inkscape and install it
  2. We’ll want to make inkscape available as a command in our terminal path. To do so, In a terminal execute create a link:
sudo ln -s /Applications/Inkscape.app/Contents/MacOS/inkscape /usr/local/bin/inkscape

3. Create a new file svg2pdf.sh with the following contents:

#!/bin/bash

# get path from command line
MYWD=$1

for file in *.svg
do
  echo $file $MYWD
  cat "$file" | inkscape --pipe --export-filename="${file%%.*}.pdf"
done

5. Make it executable:

chmod +x svg2pdf.sh

Usage

Run the script with the path to the folder filled with *.svg files to be batch converted to *.pdf.

Example:

bash svg2pdf.sh ~/Documents/folderOfSVGsToConvert

This will convert all svg files in the given directory into pdf.

Next you can use Adobe Acrobat, Preview, ghost script or many other programs to combine them into one single pdf file instead of multiple pdf files.

Combining Multiple PDFs into a Single PDF

Combining with Preview

The simplest way to combine multiple PDF files into a single one on Mac OSX is to using Preview.

A screenshot showing Preview application and how to open them thumbnails pane in the menu by opening View → Thumbnails or pressing Option + Command + 2. Which is handy for combining PDFs after batch conversion of svg to pdf files.
  1. Open the first page with Preview.
  2. Open thumbnails pane in the menu View → Thumbnails
  3. Drag and drop each PDF file into the thumbnail pane in the page order you’d like.

Combining with pdfunite

Install poppler, a PDF manipulation toolset.

brew install poppler

You’ll now have pdfunite command available, run it on your directory of PDFs to create a single PDF.

pdfunite *.pdf book.pdf

Speaking of Books

Looking for good engineering books? Take a look at my top rated engineering books I’ve found and recommend!

Book Reviews

Creativity INC. – Book Review

Leave a comment

Creativity Inc. is a delightful & fairly easy read. I enjoyed it, however didn’t get much practical value out of it.

Cover of Creativity Inc.

Rating

(Higher is better, 5 is neutral)

  • Would I recommend? 5 / 10
  • Did I learn anything? 5 / 10
  • Did I learn anything I can apply? 2 / 10
  • High information density? 3 / 10
  • Would I re-read? 3 / 10

Buy Creativity Inc. on Amazon

Creativity Inc Overview

Gems of information are tucked away amongst history around Pixar. You’ll have to sift through stories about Toy Story, Bugs Life, and other films along the way of finding ideas to ponder.

Reading this book you’ll learn more about Pixar’s history than what makes thriving creative workplace. Though

Who should read Creativity Inc?

If you love Pixar, I highly recommend Creativity Inc! You’ll have much deeper love and appreciation for everything they create.

However, I likely won’t be recommending to anyone for personal growth or learning. I may recommend it to Managers & Directors who are scaling a company up. It could be encouraging read to reflect on what team culture to defend and keep as well as how to adapt as an organization grows. Though this book doesn’t dive into concrete advise.

My main takeaways from Creativity Inc.

Creativity is fragile. Do not shut ideas down, give them safety and build upon them.

Self expression is important, allow folks to decorate their workplace and share their passions they have outside of work.

A select group of employees will “get it” and be rockstars, value them. However, I’m not sure if I agree with Pixar’s “Braintrust”. While open radical candor is very important, I feel it places a select few into an elite few. It doesn’t seem this is Pixar’s intent with the Braintrust since advise (“notes”) are optional. I think I’d rather a pattern when all can provide radical candor regardless of status. Creating a Braintrust creates an inner circle club.

If you liked this book, next I’d recommend:

Going deeper on team culture: Debugging Teams
Going deeper on leading with positive impact: Multipliers

Favorite Quotes

“[…] managers must loosen the controls, not tighten them. They must accept risk; they must trust the people they work with and strive to clear the path for them; and always, they must pay attention to and engage with anything that creates fear.”

“For all the care you put into artistry, visual polish frequently doesn’t matter if you aren’t getting the story right.”

“Finding and fixing problems should be assigned to every employee. […] ownership of and responsibility for a product’s quality to the people where most involved in its creation. […] You don’t have to ask permission to take responsibility.”

“If you give a good idea to a mediocre team, they will screw it up. If you give a mediocre idea to a brilliant team, they will either fix it or throw it away and come up with something better.”

“Find, develop, and support good people, and they in turn will find, develop and own good ideas.”

“You are not your idea, and if you identify too closely with your ideas, you will take offense when they are challenged. To set up a healthy feedback system, you must remove power dynamics from the equation – you must enable yourself, in other words, to focus on the problem, not the person.”

“Candor is only valuable if the person on the receiving end is open to it and willing“

“Failure, when approached properly, can be an opportunity for growth. […] To be wrong as fast as you can is to sign up for aggressive, rapid learning.”

“If we allow more people to solve problems without permission, and if we tolerate (and don’t vilify) their mistakes, then we enable a much larger set of problems to be addressed.”

“Managers, afraid of appearing to not be in control, believe that they have to know everything – or at least act like they do. […] The better approach, I believe, is to accept that we can’t understand every facet of a complex environment and to focus, instead, on techniques to deal with combining different viewpoints.”

Project Management

Why We Should Consider 1 Week Sprints.

Leave a comment

You know how 2 week sprints are the de-facto go-to pattern for many teams? I don’t believe they are the best for teams and we should all consider 1 week sprints instead, and I’ll tell you why.

The Downfalls of 2 Weeks Sprints

  • Longer meetings to plan for 2 weeks
  • Need more Context
  • Hard to estimate how much work can be accomplished
  • Over commitment is easy
  • Doesn’t accommodate changing requirements
  • Doesn’t accommodate newly discovered scope as well
  • Doesn’t accommodate surprises that pull for attention away from the team (support, external teams)
  • Can create anxiety when falling behind, especially considering work remaining
  • PMs have less certainty on sprint progress
  • Slow feedback cycle

The Upsides of 1 Week Sprints

  • Tighter feedback loops
  • Shorter meetings
  • Allows team to be more precise in their commitments
  • Forces team to think about the now (highest priority).
  • If scope or focus change occurs, only interrupts 1 weeks worth of work.
  • If over commitment occurs it is smaller and easier to correct.
  • Generally feels more exciting, each week starts anew.
  • Weekly routine lightens the mental load

Won’t 1 Week Sprints have more meetings?

Since we have only one week to plan for, we must have more meetings, and this take more time right? Surprisingly you’ll spend less time in meetings!

Touching base on a weekly basis there are fewer surprises and thus fewer ‘new’ topics that need to be introduced.

For instance, when we are driving a car, it’s natural to drift a little side-to-side within our lane. But, instead of large jarring adjustments every minute, we make many frequent little adjustments keeping us centered on the road and therefore moving smoothly around every turn along the way.

Similarly, frequent touch bases are simpler and shorter, and therefore also keep the team in sync moving smoothly through their work.

Now let’s take a look at what a 1 week sprint schedule might look like.

The 1 Weeks Sprint Schedule

Here is what a possible 1 week Sprint Schedule could look like.

Outside of this schedule there still may be additional team meetings such as Project Planning, Project Kickoffs, or Planning Quarter Roadmap.

A week calendar view showing the meetings on each day including standups, grooming, retros, and demos. There are only 6 meetings displayed in total. Standups shown every day at 10am, three of which are longer in length because they include Scope, grooming, and demos. Retro remains it's own meeting.
A sample 1 week Sprint Schedule
Standup (15min) – Everyday at the same time, occasionally bundled with other team meetings.

* Touch base to talk about work in progress
* Update team members of any changes or needs

Week Scope (30min + 15min Standup) – The kickoff for the week.

* Review Previous Sprint metrics, work completed
* Review Previous Sprints remaining stories that will cary over to this weeks sprint.
* Define the weeks big picture focus for the team
* Pull in new stories & Prioritize them
* Pull in/out stories until matches teams throughput (don’t compromise and over commit!)
* Confirm the scope committed to
* End with Standup

Grooming (15min + 15min Standup) – Looking forward to future work and estimating stories

* Start with standup
* Introducing upcoming work & projects
* Breaking down, defining, and estimating stories
* Delegating project leads for spike work

Retro (30min) – How can the team improve

* Depending on how well the team is running this can be every 2 weeks instead of every week.
* Retros should always focus on how the team can improve to become the best team.
* Retros can be sometimes heavy. Therefore Thursdays tend to be best to avoid ending the week with any weight.

Demos! (15min + 15min Standup) – Celebrating the weeks wins!

* Start with Standup
* End the week with great for team morale
* An open form where any team member may share work (in progress or completed) from the week
* Great for knowledge sharing
* Ends the week on a high note.

(expand each section above for a detailed description & structure)

Bundling Team Meetings with Standup

Folks tend to prefer fewer meetings. A clever tool to utilize – combine meetings together that have the same or similar attendees.

In the sample 1 week sprint schedule above, we’ve combined Weekly Scope, Grooming, and Demo meetings with standup. This takes 9 meetings down to 6. Everything is simpler and lighter.

Summary

It’s worthwhile to consider switching your team to 1 Week Sprints. They will give your team more energy and more accurate commitment to their work. 1 Week Sprints will set your team up for even better success.

What does your team use? Would you ever switch?

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

setup VSCode with REACT_EDITOR (or any editor)

Leave a comment

When an error occurs with an app Created with Create React App the error screen is super helpful.

You can click on this error in the browser to jump directly to the line of code inside your editor! But how do you setup VSCode with REACT_EDITOR?

Console error:

Could not open SomeFile.js in the editor.
To set up the editor integration, add something like REACT_EDITOR=atom to the .env.local file in your project folder and restart the development server. Learn more: https://goo.gl/MMTaZt

Setup your editor to be open from terminal

Google “How to open [your editor] from terminal” to find instructions for your editor.

For VSCode, open the command pallet ( Command Key + P ) and type > shell to install “code” into your PATH environment variables.

You should now be able to open terminal and type code to open VSCode. Pretty nifty!

Setup your React Project to know which editor to open

Create a new file (or edit the existing) .env.local file.

setup VSCode with REACT_EDITOR this will be REACT_EDITOR=code and for other editors set it to the command you found to open your editor from the terminal.

Credit to this StackOverflow Answer.

Related post: Favorite Sublime 3 Packages

(cover photo credit: Jonathan Stassen / JStassen Photography)

Project Management

How do you define a critical path

Leave a comment

With any application there are parts that are more critical if they break Other areas are less critical, but nice to have. How do you figure out which are part of your Critical Path?

A Critical Path is considered: Anything that inhibits a necessary core functionality.

It’s easy assume to assume we already know what is Critical or not in our applications. It’s good to have a strategy to evaluate the criticality of one feature to another.

Understanding what features are Critical Path helps understand things like: urgency of fixes, amount of unit/automation testing should be written, and amount of time to invest in making it resilient to failure.

Create a list of features

List out features of your application, both small and large. This list should be extensive. Collaborating with team members is a great way to remember every little features that exist.

Next we need a way to score and compare features.

Create a Critical Path Rubric

Create a list of questions to evaluate features against each other. Here are 7 great questions to ask of each feature to test if it’s a Critical Path feature:

(Click to expand each)

1) Does it have a high volume of usage?

Example: On this blog articles are ready many times a day, search only used a couple times a week.

Does the system, workflow, or feature see more than X volume of usage per day?

One of the simpler tests at first blush, how much is it used. However, personal anecdotes, preference, and bias can cloud our judgment of what the most used items are.

If we aren’t measuring usage, then we can only guess with an anecdote how much something might be used. Thus it’s important to truly add monitoring to systems.

When we can measure the volume of usage the feature or workflow by users. Each time a someone uses a feature or system we can consider it a vote towards that item.

2) If it broke would it disrupt / make common workflows unusable?

Example: Does it prevent the user from getting to other Critical Paths, like replying?

Often there are single spots of failure in a workflow. For instance maybe there is only one ‘next’ button on a view. Without it there is no other way to progress to the next step. The only option they may be to give up on what they want to accomplish until its fixed.

3) If it broke would there be a comparable workaround?

Example: Instead of logging into a site with Facebook Login, logging in with username & password.

This one is a counter point to the previous, even a workflow is common, there is a second way to accomplish the workflow. It might not be perfect or ideal, but the support team can direct users to the alternate path while the main workflow is repaired.

For example there might be multiple places on a site a user could go to try to remove a photo they posted. If one page doesn’t seem to be working, a user could go to another view that also shows your photo and try there.

4) If it broke would support receive a moderate to large volume of calls?

Example: Severity 3 or higher

This also builds upon the previous, if the support team does receive calls about the broken workflow, what would the anticipated call value be? If the volume would be large and overwhelm them, the feature is likely part of a Critical Path.

5) If it broke would we consider an app-wide rollback instead of a bug fix first.

Example: All images are failing to load.

App-wide rollbacks are fast, they quickly switch code back to how it was a couple hours or days ago. This is a great option to leverage when something critical breaks, but it’s not a lightly taken path as it will also roll back any other fixes or features that also would like to be out.

If rollbacks are on the table as an option if a specific workflow were to break, it most certainly is considered a critical item.

6) Would a customer consider leaving if it was broken for more than a week?

Example: Unable to reply to emails.

Customers and users depend on your application, they form a dependence on it work and working well. If something they consider critical within your app breaks, the trust in the reliability is eroded.

Some items might be so critical to a customer that they may even consider canceling if it was broken for a significant length of time.

They won’t probably cancel because they can’t change their profile photo, but other functionality they most certainly may.

7) Would the CEO be asking questions if it was broken?

Example: Inbox failing to load / empty, red bars, and mayhem.

The CEO carries weight and has their values. If something major breaks the CEO will know and be aware. If a workflow is so critical that they would be made aware of it breaking, you can guarantee it’s likely critical to the organization.

Score and Rank Features

Looking at each feature score each feature’s Criticality using the questions you’ve developed.

For example you could use a 1-5 points scoring.

  1. Not Critical
  2. Hardly Critical
  3. Somewhat Critical (Neutral)
  4. Critical
  5. Very Critical

Once scored, what do we do with this new understanding?

Conclusion

With these tools at hand, there is now a way to understanding what features are Critical Path.

There is a method to understanding the urgency of bug fixes. You know the areas of the application that more unit/automation testing focus should be put. And can start to think about investing in making these features more resilient to failure.

Building with intentionality around Critical Paths can take your application to the next level of reliability.

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

Planning Quarter Roadmap for a Team

3 Comments

Planning quarter roadmap and which projects to tackle is daunting.

It’s a lot to think about: What’s most important, What are quick wins, What work needs to be finished, Which stakeholders are most important.

Time to build matters

It’s easy to overlook the size of projects and how long they will take: Requirements are vague, Designs don’t exist, Dependencies are unknown — Everything is guess work.

Including the Team to Discover Scope

It’s tempting to hold tightly what projects are being dreamed of, holding them close until the start of the next quarter — revealing them at a kick off. Keeping the roadmap a secret is dangerous.

Two things this can cause:

  • Surprising the teams that will be building the projects, they have many questions.
  • The time and effort wasn’t decided by the team that will be building the projects, it was likely assumed.

Therefore it’s important to pull in the team to help build out the next Quarters roadmap. It should be clear they likely won’t be making decisions of what gets prioritized. Leveraging the teams to understand the systems that are in place, project managers can work with the team to understand guesstimate time range or amount of effort it might take to accomplish the possible projects project.

  • Better estimates of projects scopes that can inform prioritization.
  • Team is excited for & already understands projects that are in the pipeline

Temptations & Warnings planning quarter roadmap

It can be tempting for a team to dive into the technical implementation of a project. This is ok up to a point, but only to a hypothetical point. The goal is to create a rough range how long it might take.

Time ranges are important. There are always surprises, both good and bad that cause projects to go faster, but typically longer than expected.

When estimating, pick a unit for the time. Let’s say a project may take 2-3 weeks – but is that with 1 person? Or a full 3 person team working on it? It makes a huge difference! When pick units, Stay consistent with those units.

An extended form of hiking in which people carry double the amount of gear they need for half the distance they planned to go in twice the time it should take.

~Author unknown

It’s very tempting to take the low estimate. Don’t use the lower estimate! Projects always tend to run longer for miscellaneous reasons (bugs, scope creep, interruptions, pto, forgotten pieces, testing). It’s much more realistic to pick something in the middle or even the pessimistic estimation. I wrote about a related topic, Why We Estimate Stories which goes further into the cautions of under estimating.

Visualizing the Estimates

I’ve built a spreadsheet layout for looking at projects that have been picked for the roadmap and how they look on a time line.

Again it’s tempting to only look at the Optimistic estimate, and it might be best to delete the Optimistic row if temped by it.

On my teams it’s very important that the entire team focuses and works on only one project at a time (else you really have 2 teams not 1 and projects take longer, gasp!). We also estimated our projects in units of “number of weeks 2 devs working” for each project which makes it super convenient to map out.

I’ve made the Roadmap Planning Template available on Google Docs. Make a copy and give it a try.

Looking at this we can see a lot of great info. For example, we can see something interesting about Project B. It’s 4-7 weeks, the team isn’t very confident in it’s scope & needs. We either need to better define the scope, cut scope, or table it until we better understand it. It puts other smaller projects at risk. Perhaps Project D is high priority to complete in Q4. There are many great conversations we can now have.

Setting Good Commitments & Expectations

There were actually Projects A – J slotted for Q4. That’s 10 projects. Working with the team, even the optimistic projection puts us at the end of Q1, and pragmatically 1/2 into Q2!

If we hadn’t worked with the team to estimate the scope we would have been blind to our commitments we almost made in Q4. While we were excited with hope about all the things we would to accomplish in Q4 we would have been setting ourselves up for failure & disappointment & poor morale. Not only within our team, but also our external stakeholders.

Conclusion

Being pragmatic about commitments planning quarter roadmap is hard but hugely important in setting a team up for success. We are inherently optimistic creatures, we want to promise & hope to accomplish more than is realistically always possible.

Finding tools to help us be honest with ourselves makes us & our teams be honest & better people.

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

Why do we estimate stories?

3 Comments

There are two reasons we estimate stories: to understand scope and then to communicate that size of that scope to others.

Understanding Scope of Tasks

In order to be effective at anything we do in life, it’s best to step back and understand what it is exactly that we want to accomplish.

  • How hard is it?
  • How complex is it?
  • Are there unknowns?
  • How long might it take?
  • How well do we understand it?
  • Are there other tasks that need to be done first?

As an individual we ponder these questions ourselves. As a team we discuss them together during our weekly scope and grooming to refine our shared understanding.

It’s easy to dismiss small tasks as not worth any further scrutiny because they feel obvious. Asking these questions takes little time. Even the simplest tasks can hold surprises if we take a moment to ask these few simple questions.

A fool does not care whether he understands a thing or not…

– Proverbs

Communicating Effort

It’s hard to express how long or hard a task is to others that are not in our domain of knowledge. Perhaps they’ve never seen what code even looks like, much less tried to program.

Thus we point and estimate stories. I prefer to call them effort points or “oof” points. How much “oof” effort does something take to accomplish.

Here is an example with my household chores.

“oof” effortStory Points~Time
Take out trashLittle “oof”11-10 min
Wash the dishesSmall “oof”310-60 min
Mow the lawnMedium “oof”51-3 hrs
File taxesBig “oof”83-8 hrs
Remodel bedroomLarge “oof”132-5 days

What’s important to notice is that Story Points / Effort doesn’t mean a specific length of time but rather an estimated time rage.

Story Points are a valuable tool to roughly translate effort → time estimations.

This gives Project Managers a way of estimating a rough expectations of when a collection of tasks might be completed. This empowers Project Managers therefor to set a realistic estimated timelines & expectations with external stakeholders for when tasks and projects might be completed. I wrote more on Planning Roadmaps & Project Estimation in another post.

Personal Cautions & Notes – Estimate Stories

  • Lean heavily on higher end time values when trying to translate points to time; that is be pragmatic.
    • It’s highly unrealistic it only takes under 1 min to take out the trash & put a new bag in, probably closer to 8 min.
  • Project managers don’t mind hearing that something is complex, big or unknown, the sooner they know this the better.
  • Project Managers love the radical honesty, it helps them set realistic expectations with their stakeholders.
  • Always round up to higher point levels if something is on the fence.
  • Talk about estimating with your team and create a good Developer Culture when you estimate stories.

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

An Introduction to Redux

Leave a comment

Redux’s ideology is a unidirectional data flow. This pattern reduces long term complexity, encourages re-usability, and generally discourages spaghetti code. 🍝

Video Series: https://egghead.io/courses/getting-started-with-redux

Terms & Descriptions

The core of everything is the Store, Action, and Dispatch. In its simplest form it’s all you technically need. From there Thunks & Sagas enhance the the tooling around the Dispatching of Actions.

Store

  • A singleton object/state for the app.

Action

Dispatch

  • You “Dispatch an Action to the Store” to update the store.
  • Dispatch sends the Action payload through the Reducer.

Reducer

  • Receives the Action payload from Dispatch and modifies the Store.
  • Reducers contain no business logic, they only modify the Store described in the Action

Thunk

  • Considered the old way, but sometimes still has great applications in simple cases.
  • You can “Dispatch a Thunk to either access state or do ajax work”
  • Within a thunk you can call additional Dispatch
  • Within a thunk you can access the state of the store.
    • Good for conditionally firing subsequent api calls, or dispatches.
    • Good for pulling together data from the store into a dispatch.
  • Good for very simple ajax calls, you can Dispatch Actions from ajax response
  • Best way to understand Thunks in my opinion is to look at the 10 lines of source code:

Saga

  • Regarded as a better replacement for Thunks
  • Can require more effort than Thunks to understand, and build.
  • Within a Saga you can access the state of the store.
    • Great for conditionally firing subsequent api calls, or dispatches.
    • Great for pulling together data from the store into a dispatch.
  • Sagas can subscribe to listen and fire when some Actions have been Dispatched
  • Great for moving side effects to be self contained instead of sprinkled throughout the app
  • Provides great debounce / cancel / takelatest logic nearly for free.
  • Can do long running / scheduled Actions
  • https://redux-saga.js.org/docs/introduction/BeginnerTutorial.html

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

Wait You Use a GUI for GIT?

Leave a comment

Yes, Yes I do!

I’m a firm believer in using whatever tool you need to get the job done.

Is there shame in using a GUI?

I’m don’t believe in shaming devs for using a GUI and not using a CLI in the Terminal.

Dev shaming is toxic. It hurts people, and that’s not what we want, we want to build each other up! We want to get excited at each others accomplishments!

The tools we use to accomplish the task don’t really matter, what matters is that we build amazing software. There is no elite-ism of using one tool over another.

“You’re not a real dev if you don’t use a CLI” is a myth. Never believe those words. You’re a real dev if you can write software that works!

Why do I use both?

Personally I really use a mix of GUI and CLI. Some tasks are quick and easy in one or the other for me. For you it might be a different mix of benefits.

I prefer GUI for

  • Quick glance context: Current branch, commits behind/ahead, conflicts, other branches status, changed file count.
  • Cherry pick lines to commit, discard lines
  • Interactive rebasing & squashing with ease
  • Scrolling through exactly what lines of code I’m committing

I prefer CLI for

  • Quickly switch branches
  • Hard reset easily
  • Pull new changes
  • Committing & Pushing
  • Adding a new remote

Let’s end the culture of Dev shaming!

A place for collecting my miscellaneous thoughts.