The 360° Developer

Disclaimer

• Not a technical talk per se’ (motivational)

• Reflection of my experiences (chew the meat)

• “A talk is not great by and of itself, but by the ideas and actions it accrues.” - Handfuls of purpose for you to glean

Outline

• The Beginning of a Journey (the problem)

• What is The 360° Developer?

• Knowledge Skills: SOLID Primer, Case Study Highlights of Design Patterns, Classes as Stories

• Personal Skills: Conflict-resolution, Mentoring

• Functional Skills: Cross-domain problem-solving

The Problem

• Tale #1 - Changed jobs from C# to Ruby

• A Big Move

A. Personality-conflict with Mentor

B. No context for Agile - ‘spike and stabilize masters’

C. Static to Dynamic

D. New Team of Experts

Root Cause Analysis

• Narrow down problem space

1. How could I up-skill myself effectively and efficiently to make maximum impact for the business TODAY?

2. Imposter Syndrome - Was I in fact a senior developer?

• 2 years of strategizing and thought, INCEPTION

Code as Poetry

• “…it is a form of literary work of expression, of feeling, of ideas with certain intensity with the use of distinctive style and rhythm”

• Harnesses all of the author

• Evoke emotions

• Historically bad poems - mastery

• Two Drivers for Mastery 1. Why Create 2. Insanely Hard

My Pursuit of Mastery

• Longest time been in pursuit of mastery in software development

• Didn’t clarify what that meant

• What did the pathway look like?

• What were the guideposts?

• Scrambling around in dark - ‘TIME + OPPORTUNITY + EXPERIENCE’ will lead me to mastery

Misnomer

• A Senior Dev in interview processes

• Experienced and Skilled in business domain

• Years of experience

• Business domain became measure of seniority

• Placed in another context - lack of vision and transferrable skills missing

A better strategy to Mastery

• Being purposeful around outcomes

• Having intent

• Clear vision

• Attainable and measurable goals

• Deliberate Practice

• If mastery is your pursuit, do you have a strategy?

My Journey

• Mental Model of THE 360° DEVELOPER

• Not a stereotype socially awkward nerd and pizza lover

• Consist of a plethora of complimentary skills

• Primary skill software development

• Broad array of secondary skills

360° Developer in a Nutshell

• Less about machines, more about people

• Less about technology stack, more about problem-solving

• Less about ego, more about solving business challenges

• Less about theory, more about practicing theory

3 Core Skill Pillars1. Knowledge-Based - knowledge needed in performing a task (noun) - Ruby, Data Structures, Cucumber

2. Personal Traits - personality characteristics that contribute to performing a task. Based on experience (adjective) - Humble, Professional, Patient

3. Functional/Transferrable Skills - actions taken to perform a task. Based on aptitude (verbs) - Listening, Leading, Problem-Solving

Misguided

• I focused solely on Core Skill of Knowledge

• I lacked effectiveness

• Analogy: Value of testing. Lost opportunity cost.

• Contrast: Fight or Flight.

Developing Software is Hard

• Knowledge Economy

• Accounting - Mesopotamia (1000’s of years old)

• First Programmers - 1800 with Jacquaard Loom

• Immature knowledge domain

• Rate of change in theory and practices

• 1950’s - 43 new languages every 10 years

Package growth35 gems

20 nuget

529 npm

Overwhelming Body of Software Theory

Data StructuresDesign PatternsImplementation PatternsArchitectural PatternsVarious Programming Languages

Programming Paradigms: OO / FunctionalLanguage IDE, Tools, Libraries and Frameworks

Testing - TDD, BDD and supporting softwareOS FundamentalsNetworking / System Administration

#1 First 20 Hours

• Plan, Think and Assess what you actually want and why

• Get expert guidance to better guide you and accelerate your learning

• Learn only the skills you need to accomplish what you actually need

Diluted Principles

Combined with Pareto Principle

• 20% of the invested input is responsible for 80% of the results obtained

• Epiphany 1: Any knowledge domain could be learnt quickly and effectively (not mastered)

• Epiphany 2: Knowing only 20% is sufficient to deliver 80% of the result

• Design Pattern revival @ Work

• Pressure of ‘not-knowing’

#2 Improving on Quality: SOLID

• Business faces problems today

• Doesn’t need the master you will be one day

• How can one make an impact today?

• Build software today sufficiently well to change your mind tomorrow

Single Responsibility Principle

• Definition: Code that has one and only one reason to change

Requirement: single blade knife

Open/Closed Principle

• Definition: Software entities should be open for extension, but closed for modification

• Open For Extension - defined extension points where future functionality can hook into existing code and provide new behavior

• Closed for Modification - No pending or resulting modification to the classes themselves

• Analogy: Hardware store, saw blades

Saw Blades

Liskov Substitution Principle

• Definition: Replace any instance of a parent class with an instance of one of it’s children without creating any unexpected or incorrect behaviours

• Barbara Liskov - “If S is a subtype of T, then object of type T may be replaced with objects of type S, without breaking the program”

• Analogy: Lenovo Laptop Charger (interface matches but the voltage didn’t)

Interface Segregation Principle

• Definition: Client should not be forced to depend upon interfaces they do not use

• Code should not be forced to depend methods it doesn’t use

• Analogy: CMS has User Class and needs Moderator

Dependency Inversion Principle

• DIP is not DI (Los Techies)

• High Level Classes should not depend upon low-level classes. Both should depend upon abstractions

• Abstractions should not depend upon details. Details should depend upon abstractions.

• Software components should depend upon abstraction instead of implementations

• Analogy: Low-level (disk, network IO). High-level (Business)

Reasons for SOLID

• Primary focus on making code adaptable (future-proofing)

• Singular body of knowledge (structured learning)

• High-return body of knowledge with measurable feedback

• Helps develop you ‘bad code sniffer’

Get a handle on improving today

Design Patterns• Apply a strategy to improving on it

• Looking for some feedback - went to case studies

• Case Study Highlights !!!

2003 A Quantitative Study of the Application of Design Patterns in Java

• Aim: Claims of DP - common design vocab and improve communication amidst developers. Lacking quantitative research as claims supported by experienced practitioners

• 1000 open source projects under source control

DP Usage

1

23

4

5

Combining 3 Cases Studies and Dr. Dobbs

• Small segway

1. Adapter

2.Command

3.Singleton

4.Factory

Back to 2003 Study Revealed:

1. Design patterns more likely to be used in bigger development teams (7+)

2. There were differences between developers who used patterns and developers who do not. Most notable was total number of code modified or added were higher by those who did use patterns.

3. The data showed very little usage of design patterns in later usage or lifecycle of code. Rarely applied in refactors

The Effect of GoF Designs Patterns on Stability: A Case Study• Aim: Understand stability of classes that participate in

instances of GoF Design Patterns.

• How stability was impacted by:

1. Pattern Type

2. Role Pattern Plays

3. Number of pattern occurrences in which class participates

4. The Application Domain

Number of design patterns in which a class participates increases, the less

stable the class becomes.

Pattern Participation• 51800 classes did not use patterns

• 10400 classes used a single pattern

• 2700 classes were used in more than one pattern

Top 3 Users of Patterns By Application Domains

• Audio and Video (31%)

• Business and Enterprise (28.8%)

• Communications (28.6%)

Most Stable Classes Used Which Patterns:

• Singleton

• Facade

• Observer

• Composite

• Decorator

• Adapter and Proxy are more unstable relationally

1999 Bell Labs: A Controlled Experiment in Maintenance

Comparing Design Patterns To Simpler Solutions

• Aim: Seek empirical evidence where using design patterns are beneficial. Particularly use of design patterns where actual design problem is simpler

• Detail: Didn’t use pattern detection tools. Used people, group of 4. 4 programs of different purpose, design patterns and maintenance tasks. 29 subjects in total, all professional engineers.

Results• It is usually, not always useful to use a design pattern if

there are simpler alternatives. Basically, if you have a simpler solution, use that.

• Patterns are sometimes superior to simpler solutions in non-obvious ways and should be used by default. If you don’t understand the trade-offs between the pattern and the simpler solution, default to a pattern

• Use software engineering common sense to find the exceptions where a simpler solution should be preferred, even if a design pattern could be applied easily

#4 The Skill of Good Analogies

• Pitch - building the skill of ‘good analogies’

• Kent Beck - 3x (simple, powerful in application)

• Avdi Grimm - Confident Ruby (Input, Perform, Output, Failure)

• Extended, classes as stories

Why Stories As Classes?• Stories have very specific target audience

• Concerted ‘effort’ to ensure readability for audience

• Stories have to make sense to be understood, clear to be enjoyed

• Good stories are coherent and pleasure to read

• Bad stories are easily detected and grate attention

• Principals of the analogies domain can guide our own

Monolithic Story• Gripping stuff (only page 1)

• Written not to be read

• Filled with Legal Jargon

• Same effect with Monolith Class

• Don’t feel like reading

• Sift before hitting jackpot

• Don’t want to read or tell

DRY Story:

Adventure Challenge Books

• Decisions determine direction and fate of main character

• 2-3 short descriptions about your options

• Enthralled with what may happen next

Example 1:

• If you want to fight the angry troll - Turn to page 137

• If you want to reason with the angry troll - Turn to page 140

Example 2: • If you fight the angry troll with your bare hands. The

troll was green, he had big eyes and boy was he mad. In fact he was so ugly he made Gollum look like one of the Kardashians. So you pick your sword and you slay him. The end. If you want this, turn to page 137.

• If you try to reason with the troll. The troll in fact doesn’t like reasoning. So you sit around for about 5 hours talking about Plato and Aristotle until you realize he is a supporter of Adolf Hitler and in one swift blow kills you. If you want this, turn to page 140.

Information Hiding

Bleeding implementation detail

Short StoriesGood Short Story: The end. Popcorn lived with their dad and mum. Once upon a time there was a little girl named Popcorn.Popcorn loved her sister Peanut and her dog Pepsi

Even Better Short Story: Once upon a time there was a little girl named Popcorn.Popcorn lived with their dad and mum.Popcorn loved her sister Peanut and her dog Pepsi.The end.

OrderBuild up

Power to Communicate

• Communicate abstract things

• Lack knowledge or expertise

• Empowers stakeholders and decision makers

• Gives them rules, principals and concepts from others bodies of knowledge they understand

• Monoliths, DRY, Information Hiding, Class Organization

Personal Traits:

• Personality characteristics that contribute to performing work (these are adjectives).

• Developed in childhood and through life experience.

A Tale Of Two Leaders

• Leader A - genius, immense problem solving, revolutionize, 2 years, failure to relate to people

• Leader B - no education, lead, CEO, multi-million rand deal, millionaire, VB6, relate to people, set a vision others follow

• Trying to change the world with code, but there is an opportunity to change the business through how we relate to our colleagues

• People matter. Actively invested in people as we are in Tech?

Our working relationships matter

The 360° Difference

• 360° Developer appreciates people

• Respects diversity in all forms, from gender, race to thought

• Disclaimer: Lacking EQ cannot change the world

• Those developers rare, it’s our relationships

Achieving Success Through Social Capital Dr. Wayne Baker

“Success is social: It depends on our relationships with others. All the ingredients of success that we customarily think of as “individual”—natural talent, intelligence, education, effort, and luck—are intricately intertwined with networks.”

Type Safety in the Workplace• Ruby types STRINGS, SYMBOLS, HASHES and ARRAYS.

• Data Types as People

• ‘Hash’ discriminates against ‘Array’ for being able to do faster lookups

• ‘Strings’ discriminates against ‘Symbols’ for being so single-minded and immutable in his opinion

• Synergy of these types that lends Ruby to be the language that it is, so too the workplace

Supporting Type Safety:

• Last year, Crucial Conversations

• High stakes, high emotion and opposing views

• Tale: Dad with two daughters

• Resource contention

• Loss of purpose

• Caring to win with Mutual Purpose

How to deal with conflict

• We tell ourselves stories about others

• Stories that deepen conflict

• Principal helped me with these stories

Supporting Type Safety:Judge Actions Not Feelings

Judge Actions Not Feelings“Only real act’s can be judged, while ‘good’ or ‘bad’ imaginary acts cannot be. Only conduct can be condemned or commended. Feelings cannot and should not be….. It takes great wisdom to realize that all feelings are legitimate: the positive, the negative and the ambivalent”.

• Value feelings and emotions and not react to it

• Embrace what their feeling as legitimate

• Extent of stories can be minimized by not judging feelings

Thinking Environment• Nancy Kline “Time To Think” - 10 principals defining a

culture

• Diluted definition: Best Described As A Safe Meeting

• Equality of thought, Safety is actively protected

• Biggest impact - Don’t teach people what to think, enable people to think

• "The task of leaders is not to put greatness into humanity, but to elicit it, for the greatness is already there."

Failed Mentorships

• Tale: Gave the answer, more or less the answer and progressed to dropping hints on how to get to the answer

• Some mentorships failed

• Thinking Environment promotes enabling others to grow and flourish their own intelligence

Principals for Enabling Others To Think

• Ask Incisive Questions - find the limiting thought or assumption

• Not statements but questions that cause mentee to think. Free them from limiting thought

• Don’t rush to correct misinformation

• Release information slowly and thoughtfully

• Only give information when it will give people a decisive difference or direction in their thinking

Functional/Transferrable Skills:

• Actions taken to perform a task (these are verbs).

• Based on ability and aptitude.

Limiting our own ability

• As Developers, problem-solving is most valued

• Limit our abilities to one domain

• Tale: Strategic involvement in a multi-million rand profitable business

• Limited mental dedication to code-only problems

• Lost opportunity to apply my problem-solving and move business forward

False Premise • Aim in life: Master Craftsman

• Dan North - GOTO 2016 “Software that fits into your head”

• Goal of software development: “Sustainably minimize lead time to business impact”

• Not there to be software craftsman, we are there to solve business challenges

• Primary and Secondary Motivation Matters

Epiphany

• Less conflict with technical decisions

• Less friction when business dramatically changes something

• Higher purpose than self

• Aligned myself with that mattered

• KEY: Opened up myself to problems beyond my domain, in line with my strengths.

Are you limiting your problem-solving domain?

• Challenge To You - To narrow a domain, Test the water, Immense Talents

• Our uniqueness brings unique-problem solving

• Not hired to be code monkeys

• Our main problem: Business challenges

Bring your thinking to the Table!

“At bottom every man knows well enough that he is a unique being, only once on this earth; and by no extraordinary chance will such a marvelously picturesque piece of diversity in unity as he is, ever be put together a second time.”

― Friedrich Nietzsche

Up-skill today

• How could I up-skill myself effectively and efficiently to make maximum impact for the business TODAY?

★Wholistic developer, 360° developer (3 pillars)

★A Well Defined Vision, with a clear strategy for execution on all three pillars

★Consistency in daily execution of that strategy

Senior Developer?• New Measure is not a title, but in 3 questions

1. Have I successfully improved on my technical knowledge? (Knowledge)

2. How have I improved as a person and in my inter-personal relationships? (Personal Traits)

3. How have I leveraged my strengths to resolve business challenges? (Functional)

• My mental model - like code imperfect!