SpringOne Tour: The Influential Software Engineer

The in
fl
uential
Software engineer
@ntschutta
ntschutta.io
Nathaniel Schutta

We tend to view software
projects in purely technical terms.

What new technology do we all
want to put on our resumes?

Resume driven design is a
real thing friends!

Doesn’t mean it’s a
good idea mind you…

Software practitioners tend to
fi
xate on technology.

It’s fun! It’s why many of us get
into software in the
fi
rst place.

Software education tends
to ignore people.

How many of you have
skipped a soft skills seminar?

Most of us learn to navigate
those waters via trial and error.

This doesn’t come
naturally to all of us.

Technology gave us an escape
from messy human interactions!

Software projects are
people projects.

Full of personalities,
emotions and opinions.

While it is tempting to focus
solely on tech, it isn’t enough.

How do you in
fl
uence people?

How do you communicate technical
messages to non technical people?

How do we do all that while still
delivering working code?

Culture? What does that have
to do with technology?

Ignore culture at your own peril.

“If they don’t change the paint
once in a while...”

Culture gets formed *very*
early in a company’s existence.

Hire, attract, retain based on culture.

During hiring, often
talk about “culture
fi
t.”

Culture informs everything we do.

Culture is where good
ideas go to die.

It is *really* hard to change.

People who have risen to
power or excelled in an org…

Have often gamed that culture.

Any change to that culture is a
potential threat to position.

“Middle management ma
fi
a.”

“That’s how we’ve always done it”.

–Upton Sinclair
“It is dif
fi
cult to get a man to understand
something when his salary depends
upon his not understanding it.”

–Niccolò Machiavelli
“[T]he innovator has for enemies all
those who have done well under the old
conditions, and lukewarm defenders in
those who may do well under the new.”

The Curse of Culture.
https://stratechery.com/2016/the-curse-of-culture/

–Ben Thompson
“culture is one of a company’s most
powerful assets right until it isn’t…”

“How did you go bankrupt?”
Bill asked.
The Sun Also Rises by Ernest Hemingway

“Two ways,” Mike said.
“Gradually and then suddenly.”
The Sun Also Rises by Ernest Hemingway

And it isn’t about buying a tool.

https://mobile.twitter.com/mattbarcomb/status/1234439273077772289

https://twitter.com/mstine/status/1326916377740005378

We don’t do that, we arrange
ef
fi
ciently placed felt lined boxes.

They relented. We got the worst
conference room imaginable.

Show success, build credibility.

Here’s what we’d like in
the next project room…

Now? IT
fl
oors are all project rooms.

But it took time. And persistence.

Simpler if you are a decision maker!

Bezos mandate.
https://plus.google.com/+RipRowan/posts/eVeouesvaVX

All data will be exposed through
a public service interface.

Services are *the* communication
method between teams.

No other form of communication is
allowed. No direct reads, links etc.

All services must be designed
to be public. No exceptions.

Don’t want to do this?
You’re
fi
red.

Unsurprisingly, things
began to change.

You probably don’t have that
kind of clout. Sorry.

–Adrian Cockcroft
“we don’t have these Net
fl
ix superstar engineers
to do the things you’re talking about”, and when
I looked around the room at the company
names my response was “we hired them from
you and got out of their way”
https://medium.com/@adrianco/you-dont-add-innovation-
to-a-culture-you-get-out-of-it-s-way-2e6148349aae

– Adrian Cockcroft
“You don’t add innovation to a culture,
you get out of its way.”
https://medium.com/@adrianco/you-dont-add-innovation-
to-a-culture-you-get-out-of-it-s-way-2e6148349aae

Sometimes, it is easier
to start a new culture.

A lab, a special
fl
oor,
a different building.

Allows you to start fresh. With
like minded individuals.

We all dream of green
fi
eld development!

Free of the shackles of the past.

This time, we’re going to do it right!

But we don’t get many of
those opportunities. Sorry.

And, even when we do, things go
sideways faster than we’d like.

You will work with code that
needs…changing.

Sorry. Comes with the paycheck.

No one get’s it right the
fi
rst
time all the time…

Leave the code better
than you found it.

Beware the arsonist
fi
re
fi
ghter.

Tend to elevate the developer that
“runs into the burning codebase.”

Without acknowledging they may
have actually started the
fi
re.

“I try to write tests, refactor the
code, improve things…”

“But my manager wants it done
fast…like that person…”

Praise people for doing
things the right way.

Take the time it takes
so it takes less time.

– Archilochus
“We don't rise to the level of
our expectations, we fall to the
level of our training.”

Understand total
cost of ownership.

Poorly named variables
and methods.

“Jeff…you named your ship Jeff…”

“Only Kathy goes into that
part of the codebase…”

How much of your code is
covered by tests?

You can still fail with
100% code coverage!

Bugs tend to hide where there
are few or no tests…

Want more code coverage?
Prominently display coverage stats.

SonarQube, PMD, JDepend,
CodeScene, CodeRush, Checkstyle.

Don’t just ignore compiler warnings.
They’re telling you something!

IDEs have built in refactoring
tools. Leverage them.

Sometimes you have to…
work without a net.

Pay down a little technical
debt each day/week.

Don’t neglect the cultural shift.

Culture is where
good ideas go to die.

All the best practices don’t
matter if they are ignored.

Expect some…discussion.
And that is fair.

Educate. Why are we doing this?

Brown bags. Videos.
Conferences.

Be critical of code. Not people.

All else fails, write with
the 3 am rule in mind.

– Charles Mingus
“Anyone can make the simple
complicated. Creativity is making
the complicated simple.”

Software is full of complexity.

https://twitter.com/Pinboard/status/761656824202276864

Overly complicated tools,
noisy technologies.

Minimize accidental complexity.

And code inevitably lives
longer than we expect it to.

https://mobile.twitter.com/themarcba/status/1367366516044427269

https://twitter.com/Grady_Booch/status/1422757825806176257

https://twitter.com/thejenkinscomic/status/1413996755126001675

Developers come
and go. Inevitable.

https://twitter.com/lout
fi
_o/status/1413928976268120066

Do you have a solid
onboarding guide?

All the one time setup you…
forget about. Write it down.

How do we share knowledge?
How do we share values?

Some systems are too formal
requiring tickets and admins.

Contact information as well as
the on call rotation.

Links to helpful things like the repo,
dashboard link, on call book.

Seriously - lots of
confusion over terms.

–Rich Hickey
“…most of the big problems we have with software are
problems of misconception. We do not have a good
idea of what we are doing before we do it. And then,
go, go, go, go and we do everything.”

Many people won’t ask…
what does that mean?

They’ll just live in the dark.

Whatever helps the
team understand.

Actively share your knowledge.

Consider a “time capsule”.

Screen cast or podcast of
what you did and why.

Take advantage of
standup, retros, pair up.

Grab lunch. Even if it is virtual.

Values matter. “New Rule.”

Do it for those that come after you.

I’d like to tell you it is easy to get
everyone to do the right thing.

Time to step out of our
technical comfort zone.

May have to practice
some in
fl
uence skills.

How do we get the
decision makers to buy in?

What techniques can we
use to in
fl
uence them?

Can be hard to convince people!

In
fl
uence the in
fl
uencers.

— Ms. Frances Willard
“A reform often advances
most rapidly by indirection.”

Rely on the strength of your
ideas and your reputation.

Your reputation speaks for you
when you aren’t there.

But you can work to change it.

Nothing wrong with bringing help!

Consider things from your
manager’s point of view.

There might be a rational
reason for current state.

What I told you was true... from
a certain point of view

Over thinking it will drive you nuts.

Speaking of cultures...
what is yours like?

Can you work within
those constraints?

It will inform virtually
everything you do.

We have to sell our decisions.

What hill do you want to die on?

More or less as soon
as it is committed!

– Ben Solo
“Let the past die. Kill
it, if you have to.”

It’s always tempting
to nuke and pave.

Don’t just dismiss existing code.

Have an app that’s delivered
business value for ten years?

Legacy tends to be derogatory.

Can be an amazing
learning opportunity!

https://twitter.com/daliashea/status/1374343674876854273

Very little room for
dogma in software.

In other words, pick your battles.

Strong opinions, loosely held?

We have to use <name of
technology> on this app.

Because…
<name of technology>.

Cool. You know the name. That
isn’t a good enough reason.

https://mobile.twitter.com/ProfFeynman/status/1081226199521808386

Anyone want to argue
tabs vs. spaces?

Cloud computing removes the one
stack to rule them all constraint.

We actually can spin up
multiple different stacks.

Polyglot programming isn’t just
a pipe dream anymore!
http://nealford.com/memeagora/2006/12/05/Polyglot_Programming.html

Pick the right tool for the job!

We aren’t forced down the
square peg round hole path.

It’s great right? Each team can use
just the right tool for the job!

Every developer will have their
favorite tools, languages, etc.

Teams will have their pipeline
preferences, meaningful metrics…

Leads to an awful lot of
ways to do a given thing.

How do we staff up? Go, Haskell,
Java, .NET, C++, Ruby, Python?

How many libraries will we
need to support all of that?

You will need some guardrails.

“Use any language as long
as it runs on the JVM.”

Pick from these 3
fl
avors. Won’t
work for you? Let’s talk.

Here is a well worn path, we
know it works, we support it.

Sprawl tends to exacerbate our
accumulation of technical debt.

Beware the Galápagos
Island project.

In
fl
uential developer uses some
esoteric language or technology.

Other times…beg forgiveness.

And then in
fl
uential
developer leaves.

One of these things is
not like the others!

Suffer with it. Maybe
rewrite it eventually.

Better to avoid that
problem in the
fi
rst place!

How do I convince my boss that
we should use <technology>?

Every technical choice
involves tradeoffs.

– Susan J. Fowler
Production-Ready Microservices
“When we
fi
nd ourselves presented with technology
that promises to offer us drastic improvements, we
need to look for the trade-offs.”

Give me a one handed
technologist.

Should we use React or Angular?

Should we refactor to microservices?

Should we be on prem
or public cloud?

It depends!
https://twitter.com/KentBeck/status/596007846887628801

Balancing those opposing
forces is the art of architecture.

No tech is perfect,
don’t pretend it is.

What don’t you like about it?

https://mobile.twitter.com/kelseyhightower/status/963428093292457984

How does it stack up to alternatives?

Harvey balls.
http://en.wikipedia.org/wiki/Harvey_Balls

How closely does does it
map to the criteria?

Angular React
Documentation 4 3
Community 4 3
Committer diversity 4 4
Codebase 4 4
Testability 4 4
Update history 3 3
Maturity 4 3

Angular React
Stability 4 3
Extensibility 4 4
Support 4 4
Training 4 4
Hiring 4 3
Corporate
fi
t ? ?
Usage 4 4

Sometimes, the strength of your
argument is irrelevant.

Decision may have been made
above your pay grade.

Or there’s just no appetite for
what you’re selling.

“How do I convince my
boss we should use X?”

They might say no. Heck, they
will probably say no.

And there may even
be a good reason!

There is no *one* right
way to do something.

And we are often faced with
“least worst” as our best case.

And sometimes we have to
make do with what we have.

Do you know what’s important
to your customer?

Do you know all the stakeholders?

You may have heard X but what
does the stakeholder say?

Not directly involved…but they
can help or hurt the project.

“The VP won’t got for that…”

Maybe we need her
in the room then?

Does the mere idea of that
person get in the way?

You can’t negotiate with
someone that isn’t there.

We have to manage
our stakeholders.

Not all stakeholders
are created equally...

Interest
Power
High
Low
Low High
Minimal effort.

Low interest? Probably not a
focus area for you.

High power? High
interest? Key people.

Make sure they get what they need.

Interest
Power
High
Low
Low High
Are they happy?
Minimal effort.

Let them come to the information.

Again, don’t waste their time.

Sometimes they only
seem low interest…

Then something triggers them,
and they’re high interest!

Ask: is there anything to
know that isn’t obvious?

Is there anything special you
need to know about?

Interest
Power
High
Low
Low High
Are they happy?
Minimal effort.
Make or break...

Some are obvious,
others not so much.

Some are so busy
they can’t be there.

They can show up at the last
minute and unwind everything.

What is the best way for
us to get their input?

Have a straightforward conversation.

They might not check up
on a regular basis.

High level summaries?
Digest format?

Interest
Power
High
Low
Low High
Are they happy?
Minimal effort.
Make or break...
Are they in the loop?

Help them feel seen and heard.

Take advantage of their passion!

Their enthusiasm can be contagious.

They will often volunteer to help!

Can I sit with you for a couple
of hours while you work?

Could you test this feature for us?

Can I get your input
on this feature?

Don’t turn away someone
that wants to help!

Disregard high interest
people at your own peril.

If you ignore them, they can
sabotage the project.

Or work against your interests.

Must understand your stakeholders.

What is the decision
maker in
fl
uenced by?

New technologies and approaches
can be a bit…overwhelming.

How do we approach someone
new to the idea?

“I’m on one of those
agile projects…”

Technology adoption is a journey.

They are where you used to be.

You can help them, you know
where the potholes are.

But they have to walk the path.

https://mobile.twitter.com/allenholub/status/1247329663568887808

Don’t be too quick to judge.

Especially “heritage” code.

Most people are trying to
do their best work.

And we may not
have all the context!

“Every single one of us is doing
the absolute best we can given
our state of consciousness.”
– Deepak Chopra

– Martin Fowler
“Change your organization or
change your organization.”

Software isn’t just
about technology.

It would be *so* much
simpler if it was!

You don’t have to settle for
being just an engineer.

Nathaniel T. Schutta
@ntschutta
ntschutta.io
Thanks!
I’m a Software
Architect,
Now What?
with Nate Shutta
Modeling for
Software
Architects
with Nate Shutta
Presentation
Patterns
with Neal Ford & Nate Schutta

Between Chair and Keyboard
Nate Schutta
Software Architect
VMware
@ntschutta
Most Mondays,
around noon Central
https://www.twitch.tv/vmwaretanzu

SpringOne Tour: The Influential Software Engineer

SpringOne Tour: The Influential Software Engineer

More Related Content

Similar to SpringOne Tour: The Influential Software Engineer

More from VMware Tanzu

Recently uploaded

SpringOne Tour: The Influential Software Engineer