Discussing with a colleague how we have been iterating on “Tech Talks” within our development teams (future backlink should go here), I learned there’s a theory for it called “Incidental and Informal Learning.” For now, I’ve included a section below to give a brief on a tech talk.
How fascinating! ＼(๏◡๏)／
What is Informal Learning?
There’s an article from Emma O’Neill on LearnUpon.com that answers this question, What is Informal Learning?.
More to come as I unpack this.
‘Tech Talk’ Brief
Our goal was to help with the understanding and adoption of Test-Driven Development (TDD). We started by licensing videos from Uncle Bob (Robert C. Martin) and his fanstatic Clean Coders website and then held an internal “Tech Talk” with an internal group of developers.
I love to iterate and discover, so through a series of “tech talks,” we came to the following format:
Length: 2 hours (120 minutes)
Split video into three segments, each segment consisting of:
Watch the video together (15-20 mins)
Split into random-ish breakout groups (no more than 5-6 per group) (10-15 mins)
go around the group and share 1-3 things that came to mind; “skepticism is encouraged”
have a group representative either remember (or write down) a few points to bring back to the larger group.
Come back together and have each group share the “gist” of their conversation (great if you can share it in chat as well)
Wrap-up (5-10mins) - what’s a “how fascinating!” moment or takeaway, and any action over the next two weeks as a result?
After our small (but mighty) five-person software company, NewFire Group, decided to join a much larger organization with a matching vision and mission, it wasn’t long before I asked myself, “What am I supposed to do as a Development Manager?”.
What is it I’m supposed to do?
As a software developer and small business owner, I thought I had nailed down the essentials for managing a team of talented software developers.
We developed a great hiring process, based on the book “Who: The A Method of Hiring” by Dr. Geoff Smart and Randy Street.
We had established a career path and salary expectations based on the great work and generosity of Paul Stovell at Octopus Deploy.
Note: while the original blog post is no longer available, Paul and Octopus Deploy still make public their Career & Compensation policies online in the Octopus Handbook.
I began to realize that what got me here, wasn’t going to be all I needed to get where I was going. It was a struggle, to say the least, but a starting point for something new. I was now part of an amazing organization, which emphasized trust and respect, servant leadership, transparency, and learning.
In the middle of this struggle, Dave Royce sent me a link to a video about Development Management. This one video has led to so many wonderful things. This amazing presentation has helped me frame my thoughts around development leadership at a large organization and discover the CircleCI Engineering Competency Matrix. Thank you, Dave!!
The level of transparency, generosity, and strategy from the CircleCI leadership team to share their matrix with the world (via Creative Commons Attribution 4.0).
The sheer difficulty for any organizaton to create something and not just call it “good enough” and move on; to do self-reflection, iterate on what you learned, and then share it with the world.
I took both the previous Career Path & Salary Espectations paragraphs we had and the CircleCI matrix and I did a very humbling deep-dive into the very phrasing of each matrix level. Don’t let the briviety deceive you. Unpacking each sentence is like uncompressing a highly-efficient, and very large, archive file. It’s a lot of work and I found more humbling than reading and reflecting on The Programmer’s Oath, by Robert “Uncle Bob” Martin from November 2015.
side-note I highly recommend Uncle Bob’s most recent update, Clean Code Episode 45: The Programmer’s Oath.
Thought Backlog
An outline of additional thoughts I have for this topic that may get added to this post in the future.
Iterative process for introducing it, by facilitating discussions, learning, and reflection (encouraging skepticism and questioning).
Use as an individual developer to provide an employer agnostic career development guide or tool.
Onboarding Process - Iteration 3 (2023)
Boster.dev - thought transparency (show versions of thoughts iterated over time, change log, feed, etc.)
Onboarding Process - Iteration 3
Process
understanding / learning / reflection
self assessment
servant leader assessment
review / feedback / coaching
individual development planning (team member-driven, leader-supported)
Details / Thoughts:
Provide a copy for personal use; feel free to use it throughout career in software (if useful)
Read through it, write questions down, research topics, and reconcile with current understanding and experience.
Sketicism is encouraged.
What do the words mean? What pictures do you see?
Schedule a 1-1 to talk through each competency.
Trust is important, otherwise they may feel reluctant to have an open conversation about what they know/don’t know, done/have not done.
This conversation is about establishing a relationship, connecting, and sharing knowledge both ways.
Important to share this is like a maturity model in that people in higher job titles may have some lower level compentencies and vice versa.
It all depends on individuals, their backgrounds, previous opporunities, etc.
This to help people grow and learn, not to demote them.
It takes a few meetings to get through it.
Plan for one program increment (1 quarter / 3 months).
Self Assessment
Highlight green for completed and yellow for areas of focus, but try to limit yellow to only 1-3.
Identify examples of what it means to have completed it or achieved it; consider proficiency vs mastery.
Year over year (only in second year of it), I’m helping document their growth in areas. It’s not about just checking a box, though, it’s about experiences and in some cases not everyone has the opportunity to level-up in a particular area.
A process for starting a greenfield or proof-of-concept project using the principles of Extreme Programming. After the first iteration of Red-Green-Refactor, I want to establish an automated build pipeline, publish test results, and code coverage results.
Create a new repository for the Proof of Concept.
Basic process
Using Test-Driven Development (TDD), complete first Red-Green-Refactor; push to changes.
Create initial pipeline to build project; push changes;
Require successful build for Pull Requests into Main branch.
Objective is to provide a public statement to state my aspiration and values similar to Robert “Uncle Bob” Martin’s Programmer’s Oath, on his Clean Coder Blog, in November 2015.
The Start
I realized I’ve been working on this idea though a variety of documents, tech talks, job postings, and profile descriptions.
I am committed to the continual learning and improvement of my craft as a Software Development Professional through the relentless pursuit of mastery in Extreme Programming (XP) principles of Test-Drive Development (TDD), Refactoring, Pairing, and Simple Design, and Clean Coding practices.
I want to use my time in this profession, to find ways of applying software and technology to worthy aspirations to help us be more human, more effective, and more intentional!
That’s a start, but there is plenty more to dig through.
Reflecting on the Original Oath
As I work through this thought process, I want to go through each of Martin’s original statements, documenting thoughts and questions with each reflection. Thinking about these as words we could offer as a promise to the world.
I will not produce harmful code.
Placeholder to elaborate…
The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate.
Placeholder to elaborate…
I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.
Placeholder to elaborate…
I will make frequent, small, releases so that I do not impede the progress of others.
Placeholder to elaborate…
I will fearlessly and relentlessly improve my creations at every opportunity. I will never degrade them.
Placeholder to elaborate…
I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.
Placeholder to elaborate…
I will continuously ensure that others can cover for me, and that I can cover for them.
Placeholder to elaborate…
I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
Placeholder to elaborate…
I will never stop learning and improving my craft.
Placeholder to elaborate…
I will continuously ensure others can cover for me, and that I can cover for them.
Elaborations:
I will not create overly complicated code that cannot be maintained by others.
I will create code that can safely and efficiently be maintained and enhanced by others after I stop working on this codebase.
Thought Backstage
A place to put information as I work on this particular thought to help with organization.
Questions / Backlog
What if we had a “Programmer’s Warranty” that made a coder responsible for their code, even after employment?
Would that cause programmers to change how they work or make it easier to abide by the oath (skin in the game)?
Transparency: how I write my code, what resources I use, do I use machine learning, coding assistance from GitHub Copilot, ChatGPT, third party libraries like Resharper, Intellisense, etc.
How to address that most people appear to take on jobs or titles that are challenging, offer growth, and not necessarily that they have mastered? This causes conflict with getting into situations without having “done this before”.
When higher-level developers, architects, and leadership “try, but fail” is too tempting to find another job, abandon those who they were leading, and “try again.” Much harder and more painful to deal with the mess and then decide whether to move on.
“Just because you can, doesn’t mean you should.”
– unknown
This quote or phrase is probably my most used when discussing technology, especially software development. I’ve marked it as “unknown” because I’m not exactly sure where I picked it up or to whom it is attributed.
As part of some great leadership training over the last few years, I now understand why it’s important to understand and think about the origins of the quotes and phrases we use.