That being said, I think that, as engineers, we tend to discount the complexity we build ourselves vs. complexity we need to learn.
— Joe Beda
Don't spend more time discussing a reversible change than it would take to make (& potentially reverse) the change
- ops: using lamdba will create a vendor lock-in on AWS, instead use the system we created for cloud deployments
- dev: that creates a lock-in on slow Ops team
- ops: but, but
From Twitter by Doc Norton (@DocOnDev)
A: How long will it take to build this simple feature?
B: Well, how should this part work?
A: We don't know yet.
B: And in this situation...?
A: We don't know yet.
B: And Here?
A: We don't know yet.
...
A: So, how long?
B: We don't know yet.
A: I thought you were professionals.
From Twitter by iamdeveloper (@iamdevloper)
"full-stack" now means you can:
build front-ends
write back-ends
handle devops
start a podcast
curate a newsletter
crack an egg with one hand
animate a Pixar movie
dunk
“A poem's never finished, only abandoned.”
— Paul Valery
It doesn't take much skill to notice a problem.
In fact, as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more.
Junior developers however, get to look at everything again with a fresh pair of eyes: they haven't learned to ignore all the quirks yet, so it feels uncomfortable to them, and they tend to question it (if they're made to feel safe enough to voice their concerns).
— Amos Wenger
You are perfect as you are. And you could use a little improvement.
— Suzuki Roshi
Q: I heard you once mention there were 2 types of programmers: Depth First Search, and Breadth First Search about how some go for a big picture and others go for close-up details. Did you ever expand on that? Or could you?
A: I should write something on it at some point, I guess. The idea is that some people dive deep into system to understand how everything works it is slower but they often learn from it and can use the underlying systems better because of a deep understanding.
The "breadth first" style is one of trying stuff out and building an intuition on a system by building experience using it. Can make a lot of progress really fast but can also make mistakes without that deep understanding.
Probably more of a spectrum? Or applying the right technique to each situation?
And we all have limits to how deep we go. At some point you have to go on faith. The kernel? The CPU arch? The compiler?
The systems we work with are way too big and complex for any one person to understand everything!
— Joe Beda
Paint Drip People
Keith Adams worked on kernels at VM Ware. Then virtual machines. Then search performance at Facebook. Then the HHVM implementation of PHP. Then machine learning. Now he’s Chief Architect at Slack. In between he worked on hundreds of little projects that lasted hours or days or weeks. Keith is a Paint Drip Person.
I was a big fan of the T model of skills, introduced by David Guest in 1991: know about a lot of things, be really good at one. The more I taught it, the more unhappy I got with the metaphor:
- Skilled people are good at several things.
- Skilled people’s interests develop over time.
- Skilled people don’t plan their next focus area. Sometimes it seems completely unrelated to their previous focus area.
- Skilled people are always exploring, just for the sake of curiosity.
- Skilled people resurrect interests sometimes.
All of these metaphor fails led me to the paint drip model of skills.
You draw a brush across the top of the canvas.
- Sometimes enough paint accumulates that a drip starts to roll.
- Once a drip starts to roll, it’s not clear how far it will go.
- You keep drawing the brush across the canvas, regardless.
“Moving the brush” is the curious exploration. Keith reports that he tries a project a week or so, but that most “don’t go anywhere” (I beg to differ). The drip rolling down is an area of specialization. Once it starts rolling, it’s not clear how far it will go. In any case, the brush keeps moving. Eventually the last drip stops and a new one starts.
“The best way I’ve ever summed up the war as I see it is that one side, our side, sees a foul as being against the rules, and if you do it too many times you have to be removed. The other side, Jimmy’s side, sees fouls as things you’re allowed to get caught doing several times, and if you don’t, you aren’t trying hard enough.”
“So you’re mad at Jimmy because you think his side cheats at life.”
“Partly. Mostly I’m mad because I’m pretty sure his side is going to win.”
― Scott Meyer, Off to Be the Wizard
See also New Jersey style vs MIT
Even if a system is designed in ways which seem — and may even be — suboptimal in its current context, it’s always the case that it got that way for some reason. And insofar as this is a system you will have to interact with and reason about and make decisions about, you will have a better time if you can understand those reasons and the motivations and the internal logic that brought the system to that point, instead of dismissing it out of hand.
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
― Hyrum Wright, 2012
- Leave Behind a Legacy...System - Video
- Kill Microservice While You still Can - Video
- Disposable Components Video
- All the Little Things - Video
The DACI acronym stands for the people who are involved in the decision-making process.
-
D = Driver. There is one driver and that person is responsible for getting stakeholders involved, gathering the input, and working with the Approver to ensure that the decision is made in the necessary timeframe. The driver need not be the person that leads the implementation of the decision.
-
A = Approver. The Approver is usually one person who is accountable for the results of the decision. The final decision is theirs alone. Less frequently, a decision will have more than one Approver, if it is affecting multiple areas of the organization and needs consensus among leads.
-
C = Contributors. The Contributors have the expertise required to make a good decision. They provide comments, recommend solutions to problems, and, importantly, represent groups of people who will be affected by the decision. The Contributors have a say in what we do, but do not have a vote.
-
I = Informed. Anyone who will be impacted by the decision should be informed about the decision once it is made. Ideally, documentation about the decision explains not just what was decided but some of the background, including alternatives that had been considered.