Python Vs. Go Vs. Rust
Python vs. Go vs. Rust. https://www.nicolas-hahn.com/python/go/rust/programming/2019/07/01/program-in-python-go-rust/ Discuss
About Me
Helping my Friendgineers whenever possible
Latest Articles
-
Dijkstra On Bugs
Edgser Dijkstra is a giant in the field of software engineering. Over his career he's said a lot about the way developers go about their business, including how developers need bugs. I don't necessarily agree, but there's a lot to think about there. -
Zero Bugs
Can you write code with zero bugs? Probably not. Can you ship code with zero known bugs? Absolutely. Can your repo be free of known bugs? It can if you want it to be. -
Emergency Procedures
Deployments should be safe. Always. But what if your system is down? Is it ok to take shortcuts then? -
Careers are Non-Linear
Most of the time, you want your career to advance. That's fine, and it might look like that to everyone else, but it won't always feel that way to you. And that's ok. -
People Over Process
It's People. It's Process. It's technical. It's socio-technical, and you can't choose one instead of the other. -
The Power Of Examples
Examples can help people learn. The more context your reader has with your example, more effective your example. -
Biases: The Tyranny Of Or
Biases blind us to choices. Usually without us even knowing it. No matter how boolean a computer is, the world is an analog place, and things are on a continuum. Our choices should acknowledge that fact. -
Simple or Easy?
Many people think simple and easy are synonyms. They're not. They're similar and related, but they're NOT the same thing. -
Governing the Commons
The 'commons' are any shared public resource. Ostrom's book says we can share them to everyone's benefit. Can we apply this to software development? -
More Error Types
You've probably heard of Type I and Type II errors, but there are other kinds of errors as well. You need to be just as careful of them as well.
Categories
it-depends
(61)
context
(53)
agile
(36)
learning
(31)
tdd
(30)
systems-thinking
(29)
code-quality
(27)
career
(22)
refactoring
(21)
planning
(20)
best-practices
(18)
code-for-the-maintainer
(18)
martin-fowler
(17)
engineering-excellence
(16)
kent-beck
(16)
devops
(15)
ownership
(15)
testing
(15)
domain-driven-design
(14)
decisions
(13)
mmmss
(12)
wip
(12)
architecture
(11)
assumptions
(11)
development
(11)
yagni
(10)
scope
(9)
software-engineering
(9)
tech-debt
(9)
book-review
(8)
code-smell
(8)
non-functional-requirements
(8)
bounded-context
(7)
documentation
(7)
geepaw
(7)
isq
(7)
naming
(7)
productivity
(7)
tyranny-of-or
(7)
api
(6)
biases
(6)
code-review
(6)
eisenhower
(6)
flow
(6)
hyrums-law
(6)
life
(6)
storytelling
(6)
big-ball-of-mud
(5)
chestertons-fence
(5)
comments
(5)
debugging
(5)
design
(5)
tools
(5)
goals
(4)
autonomy
(3)
done
(3)
drive
(3)
feedback
(3)
hillel-wayne
(3)
models
(3)
observability
(3)
purpose
(3)
user-stories
(3)
value
(3)
broken-window-theory
(2)
change
(2)
continuous-learning
(2)
customers
(2)
date
(2)
deming
(2)
drucker
(2)
dry
(2)
errors
(2)
legibility
(2)
measurement
(2)
mobbing
(2)
noestimates
(2)
ooda
(2)
partners
(2)
pm
(2)
priority
(2)
prs
(2)
rca
(2)
readability
(2)
rubber-duck
(2)
teams
(2)
tim-ottinger
(2)
time
(2)
tradition
(2)
unit-test
(2)
virtues
(2)
wat
(2)
winnie-the-pooh
(2)