January 10-11, 2019
with David Neal
“Punching Bears” = doing really difficult things. Have you punched any bears today?
Many developers who get promoted to management enter a cycle of being promoted, then leaving their job to get back into coding. Only to be promoted to management again.
Leadership is not just for people in management, “it’s for ALL Y’ALL”. Being a leader means speaking up for the betterment of the group, setting an example with your own behavior, having tough conversations.
David attended an emerging leaders group that met to actively develop these skills.
Negotiation is a leadership skill.
Leaders strike the right balance of compassion, care, and empathy.
Humility is not thinking less of yourself, but thinking of yourself less.
– C.S. Lewis
DISC analysis can help you to understand the different personality types at play on your team. Particularly, which ways they can best absorb information
A lion tamer’s whip does nothing to the lion–it’s just for show. What really tames the beast is the chair. When the tamer presents the lion with its four legs, the lion becomes paralyzed trying to decide which one to go after.
There are three sure things in life: death, taxes, and PowerPoint.
When you punch the bear of sharing what you know with a group, everyone wins. Your audience absorbs what you have learned, and you harden the lessons in your own mind through refining them for presentation.
Life is too short to work somewhere that stinks.
But before you jump ship
Life is too short to let things stay the way they are.
We commonly pay great tributes to our co-workers when they quit or retire. Why wait? Publicly acknowledge them and their work while they’re still there!
with Andy Lester
Experienced software developers are often surprised and frustrated at what newer developers don’t know.
#and line breaks.
Academic: "What is your company really looking for? Java? SQL?"— Tom Callaway (@spotrh) January 8, 2019
Me: "Proven problem solving skills."
with Jeff “Cheezy” Morgan
Continuous Delivery in this context is the practice of deploying software to production with every source control commit.
The goal of this practice is to run experiments in Production with customers to quickly build better software products.
Users lie about what they want. For better guidance/intel, watch what they do.
There is no testing phase.
Cheezy refers to smaller (non-end-to-end) integration tests as unit tests, to keep the pyramid simpler.
Fewer User Tests, more Unit Tests. Whenever possible, test something using a Unit Test. The team should do what it can to convert existing User Tests into Unit Tests.
A group of 22 teams (5 developers and 1 tester per team, working on the same codebase) produced a suite of 40k User Tests and 2k Unit Tests. The suite never ran to completion–it would churn on for nearly 2 days before someone had to stop (or restart) it.
Working together in pairs and mobs, the teams converted User Tests to Unit Tests until they had closer to 150k Unit Tests. Now the suite runs to completion all the time.
The remaining Manual tests are all exploratory in nature, things that automation could not accomplish. Developers participate in manual testing efforts.
Things like visual appearance, accessibility, compliance (like OSS license checking), security, performance can all be automated and integrated into the pipeline.
An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).
– Neal Ford, Building Evolutionary Architectures
Developers do not depend on QA to validate their software for them–they depend on assistance and coaching from QA so that they (the dev team) can better validate their software for themselves.
“This is done!” < “I think this is done. What did I not think of?”
Agree on a common checklist (like a Definition of Done) for each change. Automate as much of it as possible.
DevOps is about giving development teams the tools to own their production pipeline and production environment.
Stop using branches in source control. They encourage more WIP (waste), and discourage merciless refactoring.
High trust development teams use pair/mob programming and develop directly on master. Low trust development teams (such as those working on an open-source project) work asynchronously and use branches and pull requests to integrate their work.
Branch-based development < Feature toggles < Feature toggles controlled by the Product Owner
Separate the idea of release from the idea of deployment. The dev team manages deployment, but gives the Product/business Owner the trigger to release features via toggling.
After a toggle has been on for a certain amount of time in production, the dev team gets notified, prompting a conversation about removing the flag code altogether.
“Feature flags are not
if statements”. Then… what? (@chzy promises he’s working on a talk that does a deep dive into this.)
Don’t track bugs. When a bug is found, stop writing new code and fix it! Like an andon cord that stops the line in a factory.
Post a sign in your team’s area showing how many days since the last bug was found.
Q: “Doesn’t the Product Owner get to prioritize which bugs get fixed?”
A: “Yes–but they already did that when they prioritized the story that the bug has broken!”
User Test Fragility usually manifests as timing issues or state (data) changes. To mitigate the latter, write your tests with less specific assertions. For example, rather than asserting that an account balance is a specific amount, assert that the amount has changed in the correct direction (increased/decreased).
An effective pipeline should run in under 30 minutes.
Blue/green deployment. A continuous pipeline to one (non-production) environment. Release is handled by swapping the environment with production, and aiming the pipeline at the environment that was previously production.
Dark deployment. A continuous pipeline to a non-production environment. Release is handled by promoting the deployment to production.
Treat your environments like cattle, not pets. To run User Tests in a pipeline, first have the pipeline create the environment from scratch (as opposed to using a persistent test environment). The pipeline will also tear it down after the test run.
Testers must become more code-y, coders more test-y, until the two become indistinguishable to anyone not on the team.
THERE IS NO AUTOMATION TEAM.
This is the worst idea.
with Steven Hicks
Embrace Stuckness. For knowledge workers, getting stuck is the job.
Escape the problem. Knowledge work presents us with analogical problems–ones that require that we make unusual connections of ideas to solve. In order to engage the part of your brain that does this, there must first be a period of incubation.
### The 4 Stages of Creativity (Jessica Stillman, 2014)
TL;DR: Take a walk. Put the problem down when you’re stuck, and do a different type of activity to allow for it to incubate in your subconscious. Conscious thought is linear, but the subconscious mind specializes in abstract and parallel processing.
This also works because when you return to the problem, you must re-learn it, which has a similar effect to explaining it to someone else. (In the future, you’re someone else).
Harden yourself. Set up your work habits and space to accommodate being stuck, so that you don’t get lost on top of everything else.
Take regular breaks (even if you’re not stuck).
Meditate to condition and observe your mind.
Browse other people’s work to see how they solved their problems.
Keep a journal.
Talk about your struggles with others.
Listen to them about theirs.