Gosling On Open Source
History lesson today. James Gosling and Open Source.
About Me
Helping my Friendgineers whenever possible
Latest Articles
-
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. -
Listen to Your Data
Your data can speak volumes to you. If you know how to listent to it. And are willing. -
What Is Performance Anyway?
Performance is more than sheer top speed and power. Before you can call something high performance, you have to know what you mean by performance. -
Time Passes
Unit tests should be idempotent. No matter how many times you run them, or when you run them, they should always give the same answer. If they don't, something is wrong. -
Licensed Engineers
It is possible to be a licensed software engineer, but almost no one has bothered. License or not, it's still Engineering -
Engineers Estimate
Engineers all make estimates. Some are good, and some aren't. That's hardly unique to software engineering. Just another way software engineering IS engineering. -
Constraints
The primary job of an engineer is to balance competing constraints to provide value. This is done via a deep understanding of the problem space, the available tools, materials, technologies, and processes, and the requirements. That's what engineering is. -
Slow is Smooth, Smooth is Fast
Sometimes you have to accept two contradictory things as true. But what if they're not as contradictory as you think? What if it's just your perspective that makes it look that way? -
Government Digital Services
You don't necessarily expect state of the art reccomendations from a government website, but if you try sometimes, you find, you get what you need. -
Best Simple System For Now
You can hack together a solution. You can overengineer something and never finish. How do you balance the two extremes? What principles help you find the best simple system for now?
Categories
it-depends
(66)
context
(58)
agile
(37)
systems-thinking
(32)
learning
(31)
tdd
(30)
code-quality
(27)
career
(22)
refactoring
(21)
planning
(20)
code-for-the-maintainer
(19)
best-practices
(18)
martin-fowler
(17)
engineering-excellence
(16)
kent-beck
(16)
testing
(16)
devops
(15)
domain-driven-design
(15)
ownership
(15)
mmmss
(14)
decisions
(13)
software-engineering
(12)
wip
(12)
architecture
(11)
assumptions
(11)
development
(11)
yagni
(10)
bounded-context
(9)
scope
(9)
tech-debt
(9)
book-review
(8)
code-smell
(8)
non-functional-requirements
(8)
documentation
(7)
geepaw
(7)
isq
(7)
naming
(7)
productivity
(7)
tyranny-of-or
(7)
api
(6)
biases
(6)
chestertons-fence
(6)
code-review
(6)
eisenhower
(6)
flow
(6)
hyrums-law
(6)
life
(6)
storytelling
(6)
big-ball-of-mud
(5)
comments
(5)
debugging
(5)
design
(5)
feedback
(5)
time
(5)
tools
(5)
done
(4)
goals
(4)
user-stories
(4)
autonomy
(3)
drive
(3)
hillel-wayne
(3)
models
(3)
observability
(3)
purpose
(3)
value
(3)
broken-window-theory
(2)
change
(2)
continuous-learning
(2)
customers
(2)
dan-north
(2)
date
(2)
deming
(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)
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)