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
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.
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.
- Leave Behind a Legacy...System - Video
- Kill Microservice While You still Can - Video
- Disposable Components Video
- All the Little Things - Video