Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ceej's how to solve it
Search
C J Silverio
August 25, 2017
Programming
6
760
ceej's how to solve it
Maxims applicable to problem-solving in engineering organizations and in all other areas of life.
C J Silverio
August 25, 2017
Tweet
Share
More Decks by C J Silverio
See All by C J Silverio
The economics of package management
ceejbot
4
1.6k
The future of (javascript) modules (in node)
ceejbot
1
290
Keeping JavaScript safe
ceejbot
3
450
work-life balance at npm
ceejbot
5
790
hash functions and you!
ceejbot
2
350
The accidental noder
ceejbot
2
150
Design Patterns & Modularity in the npm Registry
ceejbot
3
190
Monitoring on a budget
ceejbot
2
290
Cheating Gall's Law: MediterraneaJS edition
ceejbot
4
340
Other Decks in Programming
See All in Programming
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
13k
状態遷移図を書こう / Sequence Chart vs State Diagram
orgachem
PRO
2
250
知って得する@cloudflare_vite-pluginのあれこれ
chimame
1
120
フロントエンドのパフォーマンスチューニング
koukimiura
6
2.3k
AIのメモリー
watany
11
920
CIを整備してメンテナンスを生成AIに任せる
hazumirr
0
180
レトロゲームから学ぶ通信技術の歴史
kimkim0106
0
130
構造化・自動化・ガードレール - Vibe Coding実践記 -
tonegawa07
0
140
効率的な開発手段として VRTを活用する
ishkawa
1
180
テスト環境にCDを導入してみた
yasaigaoisi
0
100
PHPカンファレンス関西2025 基調講演
sugimotokei
5
930
テスターからテストエンジニアへ ~新米テストエンジニアが歩んだ9ヶ月振り返り~
non0113
2
240
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
Building an army of robots
kneath
306
45k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Balancing Empowerment & Direction
lara
1
490
Code Review Best Practice
trishagee
69
19k
Documentation Writing (for coders)
carmenintech
72
4.9k
How to Ace a Technical Interview
jacobian
278
23k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
A better future with KSS
kneath
238
17k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Transcript
ceej's how to solve it
ceej's how to solve it, or engineering at npm
a series of maxims & their application to problem-solving of
diverse kinds
None
dedicated to David Zink with whom I have spent 20
happy years arguing about all this
it takes decades to get good at writing software
most human beings learn complex skills through mentorship
most programmers learn by working with more experienced programmers
our industry's booms have caused shortages of experienced mentors
exacerbated by a modern contempt for anybody over 40
too often programmers come of age without experienced people around
them
we keep re-inventing core tenets of our profession
npm's engineering staff meeting me attempting to share what I
know and let you share what you know
lift each other up
therefore... this talk
None
systems are how things work together
the npm's registry is a system
npm itself is a system!
systems analyst once the title for people who do what
programmers do now
systems exist in a constant state of failure The Systems
Bible by John Gall
"Every complex working system can be shown to have evolved
from a simple working system"
from this we extract a maxim...
write the simplest thing you can, every time
evolve your simple systems to do more keep them working
the whole time
this is true for people systems as well as for
computers & code
Simplicity is prerequisite for reliability. —Edsger W. Dijkstra
simple is not the same as easy Rich Hickey: Simple
Made Easy
Do the simplest thing that moves you toward your goal
while preserving your flexibility. —ceej
None
modularity
modularity is one of the big secrets
modularity is hiding the details of an implementation
if you hide the details you can change it later
the other secret is that change is guaranteed so prepare
for it
the easy connection is with what npm does: we manage
a javascript modules
modularity's more important applications are at a systems level
we hide our data storage implementations behind microservices
nobody knows if we're using mysql, postgres, or mongodb we
can change it without other services caring
just did this to the downloads API mysql ➜ redis
None
always pronounce the names of things in the funniest possible
way
don't let the perfect be the enemy of the better
than what we have now
continuous improvement our products, our processes, our systems
iterate toward victory!
don't be clever
don't be clever “Debugging is twice as hard as writing
the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. ” —Brian Kernighan
None
think
the RFC process is about stopping to think
what problem are you solving?
Defining the problem clearly helps you understand what a solution
looks like.
RFC stands for request for comment
seek feedback
None
people make the best decisions they can given their information
& abilities
improving the quality of your information will improve your decisions
give good feedback in return
your colleagues rely on you just as you rely on
them
tie your ego to being right in the end not
to being right from the start
None
you can't fool me, young man. it's tradeoffs all the
way down
what's a tradeoff?
you accept something that's meh in one way but that's
great in a way that matters more
every solution to a problem requires tradeoffs
make tradeoffs with your eyes open
None
I'll phrase that more positively
be kind be courageous
be kind to each other
kindness doesn't mean never saying hard things
kindness shapes how you say them
what does courage have to do with problem-solving?
be bold about tackling hard problems
be bold about re-examining what we do now
sometimes you need to blow everything up
None
the companies that survive are phoenixes
all code has a lifespan
code is originally written to solve a specific problem
our understanding of the problem changes the context around it
changes the code itself changes
plan to replace all solutions to problems
feel good about how long your solution lasted!
None
how we deal with mistakes is important
because mistakes are inevitable
we try for blameless postmortems
we redesign processes when things go wrong
the right thing to do should be the easiest thing
to do
work hard to make the right thing easy
do small things daily to tidy up
None
None
all code is communication
all of our work requires communication
learning our professions requires communication
how much time in each day do you spend talking
to your colleagues?
do the work to get better at communicating
find where you can get better & do it! writing?
chatting in slack? listening to feedback? giving feedback?
communication skills always pay off
None
never be cruel or cowardly if you are always make
amends -- The Twelfth Doctor
None