For my friendgineers
Articles
Categories
About
Search site
Mastodon
Github
Twitter
LinkedIn
RSS Feed
June 21, 2019
by Leon Rosenshein
Write It Down
Infrastructure As Code
Immutable
Infrastructure
About Me
Helping my Friendgineers whenever possible
Latest Articles
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.
AI Isn’t The Answer
There are lots of things that can slow down software development. Typing speed is almost never the biggest slowdown. So something that eliminated the typing speed bottleneck isn't going to make things faster.
But The Requirements Just Changed
Often it looks like the requirements have changed, but when you look closer, that's rarely the case. Instead, what really happened is that you learned more about what the requirements always were.
New Code Vs. More Code
Just like the code we write is going to be read far more often than we write it, the amount of code we change/extend is MUCH higher than the amount of code we write from scratch. So don't forget, when writing code, you, or someone you know, is going to have to extend it. So be prepared.
Categories
it-depends
(67)
context
(59)
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)
domain-driven-design
(16)
engineering-excellence
(16)
testing
(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)
isq
(7)
naming
(7)
tyranny-of-or
(7)
api
(6)
biases
(6)
chestertons-fence
(6)
eisenhower
(6)
flow
(6)
hyrums-law
(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)
drive
(3)
hillel-wayne
(3)
models
(3)
purpose
(3)
value
(3)
working-backward
(3)
broken-window-theory
(2)
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)
pm
(2)
priority
(2)
prs
(2)
rca
(2)
readability
(2)
rubber-duck
(2)
simple
(2)
teams
(2)
tim-ottinger
(2)
tradition
(2)
unit-test
(2)
virtues
(2)
wat
(2)
winnie-the-pooh
(2)