Software developers are intended to be massive, highly leverageable value creators for their companies and teams - using their creative and technical talent to build products themselves or mission-critical systems that facilitate the delivery of value inside the business. The blunt truth, however, is that many software developers would screw up tying their own shoes when left to their own devices. There's an abundant corpus of work out there on how managers routinely let down their software developers through insufficient planning, communication, listening, and support. In this talk we're going to explore the inverse - how individual software developers contributing to a project unintentionally sabotage their teams, their companies, their projects, and themselves through: * Immutable technical preferences + biases; * Bad attitudes; * Poor listening; * Inflexible and unproductive learning styles; * Risk aversion; * Incuriosity; * And more! Most importantly, in this talk we're going to try to address how we can help shift developers who want to learn and improve, but are have trouble executing, become the high value contributors they'd like to be.

1. SOFTWARE
DEVELOPERS
DESTROY
BUSINESS
VALUE
And what to do about it!

2. ABOUT ME
12 years experience leading startup
technology companies:
• Maintainer of Akka.NET project for 10
years (100+ contributors)
• Delivered products in SaaS, payments
processing, marketplaces, components,
and more.
• 9 years of consulting experience across
manufacturing, defense, healthcare,
sports betting, finance, banking, and
more.

3. SOME OF THE CHARACTERS WE’RE
GOING TO MEET TODAY
The Pet Technologist “I’m just gonna code”

4. SOME OF THE CHARACTERS WE’RE
GOING TO MEET TODAY
The Precautionist The Futurist

5. REST OF THE CAST
The Cargo Cultist The Frameworker

6. WHAT IS “BUSINESS VALUE” FOR
SOFTWARE DEVELOPERS?
• Create value for customers:
• Bug fixes
• Experience improvements
• Performance improvements
• New features
• Create value for employer:
• Expanding access to markets
• Reducing costs
• Resolving customers’ sales objections
• Create products from nothing

7. WHO IS RESPONSIBLE FOR WHAT?
What our talk is about

8. REASONING ABOUT PERSONNEL
• Attitude – does this developer have the right outlook / values to
do this role?
• Aptitude – does this developer have the right skills and abilities
to do this role?
• “Right seat” – is this developer best suited for this role given
their preferences, skills, career aspirations, and track record?
• We’re going to try to address fixable Attitude and Aptitude
problems today.

9. A NOTE ABOUT COACHABILITY
•“You can’t save anyone who doesn’t want to save
themselves”
•Developers who aren’t coachable aren’t savable
•Skip this presentation and fire them
•For everyone else, read on

10. “VALUE DESTRUCTION”
• Destruction of options:
• Hindering company’s agility to respond to new opportunities
• “Blind alleys” – building the right thing the wrong way
• Demolishing profit margin:
• Inability to translate software to unit economics
• Poor understanding of cost-drivers
• Poor understanding of performance
• Increasing opportunity costs:
• “False starts” – building the wrong thing entirely
• Frameworkism – indefinitely work around soft edges of hard problem

11. DESTRUCTION OF OPTIONS
Rapid Technical Debt Accumulation

12. HOW DO OPTIONS GET
DESTROYED?
Attitude Issues
• Insufficient interest or consideration to
business requirements in the first place
• Overfitting design of software to
today’s requirements at the expense of
likely future requirements
• Making software design choices
independently from business
requirements
Aptitude Issues
• Not able to accurately assess technical
risks and trade-offs within domain
• Difficulty socializing trade-offs, options
with non-technical stakeholders

13. “
”
ALL OF OUR WEAKNESSES ARE OUR STRENGTHS
TAKEN TO AN EXTREME

14. “I’M JUST GONNA CODE”
• Attitude: “coding is what I do – I’m just
going to stick to the spec and code”
• Communication Breakdown: feedback
on the non-technical requirements will
be non-existent; zero planning
• Impact: misalignment between output
and business needs – immediate
technical debt or missed opportunities.

15. DEALING WITH “I’M JUST GONNA
CODE”
• Attitude - disempowerment:
• “The requirements are going to change anyway, so why bother learning them”
• “This domain is complicated and I’m never going to learn anything like it again on
another job”
• Attitude – inexperience and misunderstanding:
• Doesn’t understand that modeling the domain is the where the value is truly created,
not the code that executes the model.
• Will spend months coding to avoid hours of planning.
• “I’m paid to code - I’ll just do that until told otherwise”
• Teach: learning how business domains work is immensely valuable to developers’
future marketability
Teach: software engineering is more than mere coding – this is an “uplevel”
opportunity

16. “YOU AIN’T GONNA NEED IT”
(YAGNI)
• YAGNI == get product out the door in
the short run
• Delivery-oriented heuristic
• Gets abused by developers as an
excuse not to consider what might
happen in the future
• Pain avoidance
• Laziness
• “You can’t predict any specific future
change, but you know for certain there
will be future changes”

17. DEALING WITH “YOU AIN’T GONNA
NEED IT”
• YAGNI is the result of short termism
• Teach: YAGNI makes sense under certain conditions:
• Preventing “frameworkism”
• Fighting scope creep
• Avoiding over-engineering on unimportant details
• Teach: YAGNI destroys options when we’re not careful:
• Dependency lock-in
• Database lock-in
• Vendor lock-in (i.e. payment processors)
• Self-fulfilling prophecies
• The longer the time horizon, the more likely “you will need it”
• “Show your work” – why won’t we definitely need this over N years?

18. “SHOW YOUR WORK”
• Have an engineering spec template that developers have to fill out for “bigger”
projects
• i.e. https://gist.github.com/Aaronontheweb/25e131e06d6ac22b23fc1f4a2c9ff42f

19. PET TECHNOLOGISTS
• “Whatever the question is, the answer is
‘MongoDb.’”
• Explicit bias towards 1 or more
technologies due to:
• Comfort;
• CV-driven development; or
• Thoughtlessness.
• Alignment problem – developers’
choices driven by personal preference,
not business needs

20. DEALING WITH PET TECHNOLOGISTS
• Pet technologists are intensely passionate and curious: rare + valuable, don’t
discourage
• Attitude problem is tunnel vision – overly focused on using the technology
• “Show your work”
• Have the developer prepare a presentation for just you on why {technology} is a good fit
for {project} given its requirements
• If the case is good, have them make it to the entire team and achieve buy-in
• If the case is not good, work with them to agree.
• Then have them use their passion to research / PoC alternatives. Make the passion a
productive positive.

21. PRECAUTIONISTS
• The reason .NET Framework 3.5 is still
used in production
• Will fight the introduction of new
technologies
• Will fight for standards, councils of
elders, aimed at limiting freedoms of
other developers
• Will establish a preferred vendor list
and exclude everyone on it
• All in the same of keeping things
“stable,” “secure,” and “safe”

22. DEALING WITH PRECAUTIONISTS
• Precautionists care deeply about the health of the business + product, fight to
defend it
• Aptitude problem: primitive risk management that works by eliminating options
• Need to train on trade-off evaluation + risk management techniques
• CI/CD + Automated testing
• Bulk heading (“containing the potential blast radius of failures”)
• Feature flags
• Process / product isolation
• OSS health checking + CVE management
• Approval gates and workflow management

23. FUTURISTS
• Polar opposite of Precautionist
• Windows Insiders
• Uses “Cloud Native” unironically
• Shiny object syndrome: wants to use
the latest thing, regardless of fit or
suitability
• Especially vulnerable to CV-driven
development

24. DEALING WITH FUTURISTS
• Similar in spirit to Pet Technologists, but not focused on a single technology
• Attitude problem: shiny object syndrome
• Aptitude problem: doesn’t understand dependency risk management + stability
• Take page out of Precautionists’ playbook here:
• Add some processes to enforce a minimum degree of maturity (i.e. we don’t use beta
packages in production)
• Establish agreement with team
• “Show your work”
• Have developer write out a maintenance plan for dependencies stretching out 2-3 years
• Require explicit contingency plans and cost-benefits analysis

25. CARGO CULTING
• There is a “one true way” to do software
• Technical purity is its own reward
• Lots of external influences, especially
on architecture choices
• Success on one project means
imposing that project’s design on
everything else
• “Expert beginner”

26. DEALING WITH CARGO CULTISTS
• Cargo cultists are often formula-driven developers
• Attitude: analysis paralysis on projects without crutch of a “proven” formula; doesn’t trust
their own judgement
• Aptitude: might not know how to deliver without the formula
• Pairing: this developer needs to pair with someone, preferably a patient one who disagrees
with them
• “Walk the plank”
• Ban any use of reference architectures or templates
• Have this developer build a throw-away proof of concept without one, preferably paired
• Dissect and discuss
• Repeat if failure
• Do not give them too much rope

27. FRAMEWORKISM
• It’s easier to work around the edges of
a problem than on the problem itself.
• “Rather than build our app, I’ll build a
framework for making our app”
• Applications require specificity;
frameworks don’t
• Total time-waster for 99% of corporate
software

28. DEALING WITH FRAMEWORKISM
• Aptitude: developer wants to stick with DRY, but at the expense of high coupling –
an experience issue
• Attitude: this is also pain avoidance – much easier to deal with abstractions
indefinitely than it is to make decisive domain choices.
• Teach: task decomposition
• Break the domain modeling problem down into smaller parts
• No “Blue Ocean” problems
• Makes decision making on individual parts of the domain less overwhelming
• Teach: DRY, like all things, must be done in moderation
• Frameworks are for infrastructure typically, not domains

29. PARTING THOUGHTS – COACHING
YOUR TEAM
• Comfort-seeking is the norm for most people
• Teach your team to take smart risks
• Mitigate + isolate side effects
• Scope decisions around duration + term
• Slow down to speed up
• “Show your work”
• “Write it down”
• “If you can’t explain it, you can’t code it”
• All of our weaknesses are our strengths taken to an extreme
• Too much DRY, YAGNI, etc will lead bad outcomes
• Discuss trade-offs frequently

30. THANK YOU
• Twitter / GitHub: @Aaronontheweb
• Blog: https://aaronstannard.com
• Company: https://petabridge.com/ - we do training and consulting!