Who Does Architecture
Not as much fun as the Steel Curtain, but a fairly light read with some deeper context. Who does Software Architecture?
About Me
Helping my Friendgineers whenever possible
Latest Articles
-
On Busyness
Being busier is better, right? Wrong. Or at least almost never. The trick is knowing the which situation you're in. -
That's The Way It Is
How you describe a situation has a lot of impact on how you approch it. Do you take away or give yourself agency? -
The Power Of No
Sometimes the fastest way forward is to say No to doing something. The trick is knowing when to say no. -
What Are You Waiting For?
Are you letting low priority work hold higher priority work hostage? If you are, are you doing it on purpose, or by mistake? -
You ARE Allowed To Think Before You Type
Test driven development, Extreme Programming, and many other approaches encourage us to start typing in code, either as a test or as functionality. That's good advice, but you should never start coding blindly. -
10 Commandments of Code Review
Code reviews are part of almost all development workflows. How you write them, read them, and respond to them says a lot about a team's culture. It's also a way to adjust a team's culture. How you use them is up to you. -
Optionality
Optionality is much more than having options. It's about making the future possible instead of boxing yourself in. -
Review Your Own Code Review
Don't just review it, review it BEFORE you show it to anyone. It's good for you, it's good for them, and it's good for your code. -
Demands ...
Providing customer value is what we’re all here for. Unfortunately, it's not the only thing we end up doing because of demands on our time. -
The Tao Of Pooh
Winnie the Pooh is just over 100 years old. You wouldn't think he has much to say about software development, let alone extreme programming, but Pooh's approach has a lot to teach us. And not just in development.
Categories
it-depends
(55)
context
(46)
agile
(31)
learning
(31)
tdd
(26)
code-quality
(22)
systems-thinking
(22)
refactoring
(21)
career
(20)
planning
(18)
best-practices
(17)
martin-fowler
(17)
engineering-excellence
(16)
code-for-the-maintainer
(15)
devops
(15)
kent-beck
(15)
ownership
(13)
testing
(13)
wip
(12)
architecture
(11)
assumptions
(11)
domain-driven-design
(11)
mmmss
(11)
yagni
(10)
decisions
(9)
development
(9)
tech-debt
(9)
scope
(8)
bounded-context
(7)
documentation
(7)
geepaw
(7)
isq
(7)
productivity
(7)
api
(6)
eisenhower
(6)
life
(6)
non-functional-requirements
(6)
software-engineering
(6)
storytelling
(6)
big-ball-of-mud
(5)
flow
(5)
hyrums-law
(5)
tools
(5)
code-review
(4)
debugging
(4)
design
(4)
goals
(4)
autonomy
(3)
biases
(3)
feedback
(3)
models
(3)
observability
(3)
purpose
(3)
user-stories
(3)
value
(3)
broken-window-theory
(2)
change
(2)
chestertons-fence
(2)
continuous-learning
(2)
customers
(2)
date
(2)
deming
(2)
done
(2)
drucker
(2)
legibility
(2)
measurement
(2)
mobbing
(2)
noestimates
(2)
ooda
(2)
partners
(2)
pm
(2)
prs
(2)
rca
(2)
readability
(2)
rubber-duck
(2)
teams
(2)
time
(2)
tradition
(2)
unit-test
(2)
wat
(2)
winnie-the-pooh
(2)