About Me
Helping my Friendgineers whenever possible
Latest Articles
-
Power Dynamics
You always need to be careful what you say, because you can't be sure how people will here it. Add in a power differential and things can easily go off the rails. -
Exsqueeze Me?
There are lots of good reasons to remove tests. There are even more reasons to keep them. Or, if there's a problem, FIX them. -
The Messy Middle
It's hard to be stuck in the middle. But if you pay attention and know that important things can happen in the middle you can turn the messy middle into an advantage. -
Speed Vs. Quality
Move fast and break things might work for a disruptive business, but as a long term coding strategy it leaves a lot to be desired. In fact, it's a self-defeating strategy. -
Culture: Not Just For Yogurt
What you do when things are going well doesn't define your culture, it just illuminates it. So changing what you do when things are going well won't change your culture. So what can you do? -
Docs First And The Definition Of Done
I'm often surprised by how clearly and fully defining your goal actually liberates you when you need to define the solution to your problem. It's almost like having too big a goal space constrains the solution unnecessarily -
System Goals
Debugability is only important if something goes wrong. Of course, something can ALWAYS go wrong. So debugability is always important. -
Superpowers And Optionality
One of the biggest superpowers you can give your code is optionality. You can do that by making sure you have clean boundaries between components. And that the components themselves stay that way. -
Coding Genies and Code Review
Reviewing your own code is critical when working with others. It's even more important when you aren't the one who actually writes your code. -
Who Are You Writing To Anyway?
An author should always keep his audience in mind. The trick is to know your audience. Even when there are 2 or more different audiences.
Categories
it-depends
(68)
context
(60)
agile
(37)
cognitive-load
(34)
systems-thinking
(32)
learning
(31)
tdd
(30)
code-quality
(28)
code-for-the-maintainer
(23)
career
(22)
refactoring
(21)
planning
(20)
best-practices
(18)
martin-fowler
(18)
kent-beck
(17)
testing
(17)
domain-driven-design
(16)
engineering-excellence
(16)
devops
(15)
mmmss
(15)
ownership
(15)
software-engineering
(14)
decisions
(13)
code-review
(12)
development
(12)
wip
(12)
architecture
(11)
assumptions
(11)
yagni
(10)
bounded-context
(9)
non-functional-requirements
(9)
scope
(9)
tech-debt
(9)
unix-way
(9)
book-review
(8)
code-smell
(8)
documentation
(8)
productivity
(8)
geepaw
(7)
hyrums-law
(7)
isq
(7)
naming
(7)
tyranny-of-or
(7)
api
(6)
biases
(6)
chestertons-fence
(6)
eisenhower
(6)
flow
(6)
life
(6)
storytelling
(6)
tuckman
(6)
big-ball-of-mud
(5)
comments
(5)
debugging
(5)
design
(5)
feedback
(5)
time
(5)
tools
(5)
change
(4)
done
(4)
goals
(4)
observability
(4)
user-stories
(4)
autonomy
(3)
broken-window-theory
(3)
drive
(3)
hillel-wayne
(3)
models
(3)
purpose
(3)
unit-test
(3)
value
(3)
working-backward
(3)
constraints
(2)
continuous-learning
(2)
customers
(2)
dan-north
(2)
date
(2)
deming
(2)
distributed-systems
(2)
domains
(2)
drucker
(2)
dry
(2)
engineers
(2)
errors
(2)
legibility
(2)
measurement
(2)
mobbing
(2)
noestimates
(2)
object-oriented-programming
(2)
ooda
(2)
optionality
(2)
partners
(2)
platform
(2)
pm
(2)
priority
(2)
prs
(2)
rca
(2)
readability
(2)
rubber-duck
(2)
simple
(2)
teams
(2)
tim-ottinger
(2)
tradition
(2)
virtues
(2)
wat
(2)
winnie-the-pooh
(2)