This is correct and insightful and all, but I’m sorry these are considered “tribes” and not just modes of operation. I’m so very tired of “tribes” of all kinds.
Tribalism is, in my mind, a shortcoming of human consciousness. One of the reasons I love programming is that it’s inherently inclusive, in that anyone (with a computer) can do it.
Yes I agree, there are more like modes. Or sides, or perspectives. I definitely recognize what he writes, but I don’t feel like I am firm in one of the camps. Most of the time I am split between 2 and 3, but there are also days that I can really appreciate a good post of someone from 1.
One reason working on a programming language is such a great activity is that you have to operate in all three of these modes. Compilers and runtimes use beautiful algorithms, you have to understand the machine to get reasonable performance, and you have users who demand ergonomics.
But really, my feeling is everyone should be able to appreciate beautiful code, optimize their code when necessary, and prioritize the customer needs first—no matter what they’re programming. So I don’t see how this is “tribes” at all.
I’ve found that to be true @ the programming language comment.
That being said, there are pure researchers say in type theory that don’t particularly care about DX or performance maybe, but in the ideas of correctness for example. And while the work this person does is pretty strongly in camp 1, camp 2 & 3 can and will learn from it as time passes.
Better question which I guess is what you’re getting at is, does someone like this find UX or hardware/performance interesting at all? And is it fine if they don’t?
I agree with your conclusion maybe because we are in a similar “camp”, but isn’t it fine for someone to disagree & only care about 1 aspect?
Sure, I think it’s OK, but limiting, to only care about one. What I’m concerned about is giving the impression you’re supposed to only care about one (i.e., pick a “tribe”).
I also think you shouldn’t frame it as tribes because everyone can benefit from learning the other mindsets.
It’s really 3 mindsets, and the best programmers can take on all 3. Everyone has their biases but the way to improve is to find the holes in your style, not to double down on a “tribe”
I credit Unix shell from moving me more toward the mindset of “making things” vs. mathematics, which I was interested in when I was younger. You can reuse code you don’t understand, and you can test anything, etc. It’s not necessarily about building up big software structures; it’s more about getting the job done
Shell is also really good for measuring performance with all sorts of creative techniques (so the hardware hacking tribe uses it)
But shell is too far on the “hack and get things done” side – it is obviously incorrect in a lot of ways so we can improve it :)
Yeah, they’re definitely valid things, but I don’t think it makes much sense to categorize people according to them.
The thing that got me into programming was definitely the “hacker” aspect. I wrote code as a kid because I loved making the computer do things, even useless things! I had to write a lot of useless things before I succeeded in doing anything of real value to me or anyone else, and I don’t think I would have kept going if I didn’t find what I was doing to be cool in and of itself.
The thing that dominates my professional life is the “maker” aspect. There’s a thing that needs to get done, I know how to make a computer do it, and people pay me for that knowledge. This relies on experience and engineering chops, but did I have those when I took my first job? Nope, except for the experience that I picked up wearing the “hacker” hat, which never stops being useful. A good understanding of the low level matters to reliability and efficiency.
The “poet” aspect is probably the one I spend the least time on, but that doesn’t mean I don’t have strong feelings about it! I love an elegant solution, and I want to take pride in the beauty of my work, not just its functionality. At the end of the day, “ugly but works” beats “beautiful but useless”, and that’s the pragmatic approach I take at work. But that’s where extracurricular programming comes in handy — I can try out new languages or techniques or constrained exercises on personal projects or things like Advent of Code where nothing is at stake but my own happiness. When you play around with the beautiful-but-useless, sometimes you find something beautiful and valuable.
And again, tying it all back in to the maker hat — a lot of that esoteric applied-mathematician stuff feels useless until you find the application that needs it and apply it yourself, and then, besides being useful, it will be concrete to you for the rest of your life, because you have the memories gained from building something with your own hands. IMO this is the real goal of a good CS education (which I never got, in the traditional way, but I’ve managed to chase down more than a few of the bits and pieces over the years).
@teh_codez linked to this from another story, so I decided to spin this off into its own discussion.
This hits close to home for me right now, because in the desktop app I’m currently developing for my tiny bootstrapped SaaS company, I’ve struggled with whether to just use Electron as the third (maker) tribe would, or try to make something efficient like the second (hardware hacker) tribe would (albeit in Rust rather than C++). I would personally be much happier with the result in the second case. But it’s possible that no actual users would care (indeed, the feedback so far during the private beta suggests that they don’t, but maybe these early adopters have better hardware than some potential users). My business partner certainly wants me to go with whatever’s expedient, as the maker tribe would. Yes, it’s about being able to make money sooner, but more charitably, I also acknowledge that it’s about getting a useful product into the hands of users sooner. But all of the negativity against Electron that I’ve taken in from programmer discussion sites makes it really hard to just plow ahead like I don’t know or care what kind of crap I’ll be inflicting on my users. I wonder how common it is for solo desktop app developers (the few that are left?) to be in this position these days.
If I were you, I think I would go with Electron first to gauge interest. If the interest is there, then you can pivot to something more efficient as a treat to yourself.
To provide a different perspective to the “well it isn’t a tribe/it’s a mindset/everybody needs to be capable of switching” theme I’m seeing pop up here.
When there is money or time involved, the tribe lens suddenly provides a lot more utility. This isn’t an abstract “oh gee I guess our value systems are different” sort of issue but instead (especially in professional settings) an existential crisis where the three tribes are actively fighting for resources. Improperly managed, this tribal conflict can kill an initiative–the best outcome is to get everybody to work together according to their strengths, but more common and nearly as effective is to remove the conflict either by isolation or purges.
I also am somewhat annoyed that the author didn’t include a wagie tribe, especially in the hindsight of the current economic anxiety: those who really and truly care more about making it through their day and getting paid than any particular concern for clean code, fast code, or delightful code and who engage in programming because it is the current strongest/safest bid to enter or stay in the upper-middle class economically. Critically, the wagies outnumber the other tribes by at least an order of magnitude and provide a natural ballast against the other tribal conflicts that would screw with their paychecks.
(Incidentally, I personally mostly prefer @geocar’s analysis from a past submission of this article, but I figure I’d kick in a different discussion point here.)
I read this earlier this week and have been thinking about it constantly since. I identified most strongly with the first camp, have been buried in Rick Hicky and Strange Loop talks since, and like @teh_codez, brought it up when telling / talking with someone in my life about the recent ‘Write Code Like You Just Learned How to Program’ post c:
I apprichiate this being explicitly resurfaced because I think it has valuable ideas to share, appreciate the number of links out to other pieces of content, and love to see that it’s been discussed before. As I ought have expected, some folks in the older threads call this post misguided and restrictive, or that it misrepresents Ada or Haskall, but I think everyone understands that a.) real works and individuals are messier, b.) everyone has their unique blend of expertise and biases, and c.) this sort of thinking can still provide a valuable mental-model for ‘perspective on perspective’ when understanding yourself and others. Only more so if we refine, consider, and discuss additional camps (like system modelers and explorers), or how one’s affinities shift across times and contexts. Gives me “Worse is Better” vibes in the way that aspects and priorities are explicitly juxtaposed.
IMO Bret Victor should not be in tribe 1, but is an archetypal tribe 3. His body of work and the talks he’s given all point in that direction. The difference is he’s also concerned about what the tool says about the toolmaker.
I think it is interesting to think about what you choose to specialise in & hone in on that.
That being said, I don’t know if we can fully understand people in other camps, which can easily lead to belittling/degrading other people’s skills simply because we don’t understand it. This article also does this from what I understand with the 3rd camp.
Or maybe more accurately we should redefine the 3rd camp. And I think a lot of people are getting misrepresented in there.
The 3rd camp should be better defined to be someone who really deeply cares about the user experience of their product above all else. They will study many different fields but only take what is needed to their product. Modern JS at it’s best is that camp, there is a lot of interesting stuff happening in modern frontend frameworks/tooling but its largely dismissed from the other 2 camps.
That being said, performance matters to UX, security matters to UX, but the primary concern is not those, its having a consistent UX.
I see people that might be thought of in other camps in this camp aswell, like matz & Guido van Rossum, I don’t know a whole lot about them, but ruby & python prioritise UX more than any other language I know of.
I think what the author points out at the end could be restated as “we should learn as much as we can from the other camps so that we can improve our own”, we can have a lot of context, but fundamentally I don’t see it possible to prioritise all 3 - mathematically correct software, hacker-level optimisations AND also UX. You can learn a lot from them, but 1 of those will stick out as primary. 1 will become the focus of that community that develops around your tooling.
So all that being said, its very clear to me that someone could develop very deeply in camp 3 & be an exceptional developer & architect AND have 0 clue how to reverse a binary tree. The crucial point I think is being missed is like, yea SURE I could learn how to reverse a binary tree I’m really quite sure its pretty trivial once I learn how, but I just don’t care enough, and when the time comes I’ll do it if I need to for my problem-space. That’s why these questions/factors we rank people by are a waste of time IMO.
This is correct and insightful and all, but I’m sorry these are considered “tribes” and not just modes of operation. I’m so very tired of “tribes” of all kinds.
Tribalism is, in my mind, a shortcoming of human consciousness. One of the reasons I love programming is that it’s inherently inclusive, in that anyone (with a computer) can do it.
Yes I agree, there are more like modes. Or sides, or perspectives. I definitely recognize what he writes, but I don’t feel like I am firm in one of the camps. Most of the time I am split between 2 and 3, but there are also days that I can really appreciate a good post of someone from 1.
One reason working on a programming language is such a great activity is that you have to operate in all three of these modes. Compilers and runtimes use beautiful algorithms, you have to understand the machine to get reasonable performance, and you have users who demand ergonomics.
But really, my feeling is everyone should be able to appreciate beautiful code, optimize their code when necessary, and prioritize the customer needs first—no matter what they’re programming. So I don’t see how this is “tribes” at all.
I’ve found that to be true @ the programming language comment.
That being said, there are pure researchers say in type theory that don’t particularly care about DX or performance maybe, but in the ideas of correctness for example. And while the work this person does is pretty strongly in camp 1, camp 2 & 3 can and will learn from it as time passes.
Better question which I guess is what you’re getting at is, does someone like this find UX or hardware/performance interesting at all? And is it fine if they don’t?
I agree with your conclusion maybe because we are in a similar “camp”, but isn’t it fine for someone to disagree & only care about 1 aspect?
Sure, I think it’s OK, but limiting, to only care about one. What I’m concerned about is giving the impression you’re supposed to only care about one (i.e., pick a “tribe”).
I also think you shouldn’t frame it as tribes because everyone can benefit from learning the other mindsets.
It’s really 3 mindsets, and the best programmers can take on all 3. Everyone has their biases but the way to improve is to find the holes in your style, not to double down on a “tribe”
I credit Unix shell from moving me more toward the mindset of “making things” vs. mathematics, which I was interested in when I was younger. You can reuse code you don’t understand, and you can test anything, etc. It’s not necessarily about building up big software structures; it’s more about getting the job done
Shell is also really good for measuring performance with all sorts of creative techniques (so the hardware hacking tribe uses it)
But shell is too far on the “hack and get things done” side – it is obviously incorrect in a lot of ways so we can improve it :)
Yeah, they’re definitely valid things, but I don’t think it makes much sense to categorize people according to them.
The thing that got me into programming was definitely the “hacker” aspect. I wrote code as a kid because I loved making the computer do things, even useless things! I had to write a lot of useless things before I succeeded in doing anything of real value to me or anyone else, and I don’t think I would have kept going if I didn’t find what I was doing to be cool in and of itself.
The thing that dominates my professional life is the “maker” aspect. There’s a thing that needs to get done, I know how to make a computer do it, and people pay me for that knowledge. This relies on experience and engineering chops, but did I have those when I took my first job? Nope, except for the experience that I picked up wearing the “hacker” hat, which never stops being useful. A good understanding of the low level matters to reliability and efficiency.
The “poet” aspect is probably the one I spend the least time on, but that doesn’t mean I don’t have strong feelings about it! I love an elegant solution, and I want to take pride in the beauty of my work, not just its functionality. At the end of the day, “ugly but works” beats “beautiful but useless”, and that’s the pragmatic approach I take at work. But that’s where extracurricular programming comes in handy — I can try out new languages or techniques or constrained exercises on personal projects or things like Advent of Code where nothing is at stake but my own happiness. When you play around with the beautiful-but-useless, sometimes you find something beautiful and valuable.
And again, tying it all back in to the maker hat — a lot of that esoteric applied-mathematician stuff feels useless until you find the application that needs it and apply it yourself, and then, besides being useful, it will be concrete to you for the rest of your life, because you have the memories gained from building something with your own hands. IMO this is the real goal of a good CS education (which I never got, in the traditional way, but I’ve managed to chase down more than a few of the bits and pieces over the years).
@teh_codez linked to this from another story, so I decided to spin this off into its own discussion.
This hits close to home for me right now, because in the desktop app I’m currently developing for my tiny bootstrapped SaaS company, I’ve struggled with whether to just use Electron as the third (maker) tribe would, or try to make something efficient like the second (hardware hacker) tribe would (albeit in Rust rather than C++). I would personally be much happier with the result in the second case. But it’s possible that no actual users would care (indeed, the feedback so far during the private beta suggests that they don’t, but maybe these early adopters have better hardware than some potential users). My business partner certainly wants me to go with whatever’s expedient, as the maker tribe would. Yes, it’s about being able to make money sooner, but more charitably, I also acknowledge that it’s about getting a useful product into the hands of users sooner. But all of the negativity against Electron that I’ve taken in from programmer discussion sites makes it really hard to just plow ahead like I don’t know or care what kind of crap I’ll be inflicting on my users. I wonder how common it is for solo desktop app developers (the few that are left?) to be in this position these days.
If I were you, I think I would go with Electron first to gauge interest. If the interest is there, then you can pivot to something more efficient as a treat to yourself.
To provide a different perspective to the “well it isn’t a tribe/it’s a mindset/everybody needs to be capable of switching” theme I’m seeing pop up here.
When there is money or time involved, the tribe lens suddenly provides a lot more utility. This isn’t an abstract “oh gee I guess our value systems are different” sort of issue but instead (especially in professional settings) an existential crisis where the three tribes are actively fighting for resources. Improperly managed, this tribal conflict can kill an initiative–the best outcome is to get everybody to work together according to their strengths, but more common and nearly as effective is to remove the conflict either by isolation or purges.
I also am somewhat annoyed that the author didn’t include a wagie tribe, especially in the hindsight of the current economic anxiety: those who really and truly care more about making it through their day and getting paid than any particular concern for clean code, fast code, or delightful code and who engage in programming because it is the current strongest/safest bid to enter or stay in the upper-middle class economically. Critically, the wagies outnumber the other tribes by at least an order of magnitude and provide a natural ballast against the other tribal conflicts that would screw with their paychecks.
(Incidentally, I personally mostly prefer @geocar’s analysis from a past submission of this article, but I figure I’d kick in a different discussion point here.)
I read this earlier this week and have been thinking about it constantly since. I identified most strongly with the first camp, have been buried in Rick Hicky and Strange Loop talks since, and like @teh_codez, brought it up when telling / talking with someone in my life about the recent ‘Write Code Like You Just Learned How to Program’ post c:
I apprichiate this being explicitly resurfaced because I think it has valuable ideas to share, appreciate the number of links out to other pieces of content, and love to see that it’s been discussed before. As I ought have expected, some folks in the older threads call this post misguided and restrictive, or that it misrepresents Ada or Haskall, but I think everyone understands that a.) real works and individuals are messier, b.) everyone has their unique blend of expertise and biases, and c.) this sort of thinking can still provide a valuable mental-model for ‘perspective on perspective’ when understanding yourself and others. Only more so if we refine, consider, and discuss additional camps (like system modelers and explorers), or how one’s affinities shift across times and contexts. Gives me “Worse is Better” vibes in the way that aspects and priorities are explicitly juxtaposed.
Very good article - l can see myself in a bit in the camp 1, a lot in camp 3, but not at all in camp 2. Gives a lot of perspective how the field is.
Haha, and you’re a true full stack when you’re in all three tribes and programming is everything.
i noted the lack of an “examples of famous developers” section for the third tribe. miguel de icaza perhaps?
IMO Bret Victor should not be in tribe 1, but is an archetypal tribe 3. His body of work and the talks he’s given all point in that direction. The difference is he’s also concerned about what the tool says about the toolmaker.
I think it is interesting to think about what you choose to specialise in & hone in on that.
That being said, I don’t know if we can fully understand people in other camps, which can easily lead to belittling/degrading other people’s skills simply because we don’t understand it. This article also does this from what I understand with the 3rd camp.
Or maybe more accurately we should redefine the 3rd camp. And I think a lot of people are getting misrepresented in there.
The 3rd camp should be better defined to be someone who really deeply cares about the user experience of their product above all else. They will study many different fields but only take what is needed to their product. Modern JS at it’s best is that camp, there is a lot of interesting stuff happening in modern frontend frameworks/tooling but its largely dismissed from the other 2 camps.
That being said, performance matters to UX, security matters to UX, but the primary concern is not those, its having a consistent UX.
I see people that might be thought of in other camps in this camp aswell, like matz & Guido van Rossum, I don’t know a whole lot about them, but ruby & python prioritise UX more than any other language I know of.
I think what the author points out at the end could be restated as “we should learn as much as we can from the other camps so that we can improve our own”, we can have a lot of context, but fundamentally I don’t see it possible to prioritise all 3 - mathematically correct software, hacker-level optimisations AND also UX. You can learn a lot from them, but 1 of those will stick out as primary. 1 will become the focus of that community that develops around your tooling.
So all that being said, its very clear to me that someone could develop very deeply in camp 3 & be an exceptional developer & architect AND have 0 clue how to reverse a binary tree. The crucial point I think is being missed is like, yea SURE I could learn how to reverse a binary tree I’m really quite sure its pretty trivial once I learn how, but I just don’t care enough, and when the time comes I’ll do it if I need to for my problem-space. That’s why these questions/factors we rank people by are a waste of time IMO.