1. 13

    Reading this made realize I don’t see myself in any of the 3 groups. I’m probably closest to a “maker”, however, the author seems to tie that somewhay to UI and “front-end”.

    I work on line-of-business systems that tend to be large and complex. In that, I most consider myself a modeler. I’m primarily about modeling systems, real and imagined, into a working program, but not through the lens of a UI (or a relational database model).

    Instead, I see functional requirements for a large, complex system being implemented in an object-oriented “domain model”.

    Am I just a dinosaur, and lonely group of one, these days?

    1. 39

      Am I just a dinosaur, and lonely group of one, these days?

      I think the author is just wrong. People really like putting things into neat little boxes, but I would guess there are more than 3 types of programmers out there.

      1. 15

        I’m going to go one further and say these 3 “tribes” are just different ways of thinking that anyone can adopt at any time, or depending on the situation. I could plausibly claim membership of a different tribe every hour of the working day.

        1. 7

          To me, that flexibility is one of the most rewarding things of the profession: I can inhabit the mindset that best fits the problem I’m currently faced with, and I find my best ideas often by flipping to another perspective.

          1. 5

            Indeed, in fact the thing that would most likely make me say someone isn’t a “real programmer” is not their membership in the “wrong tribe”, but rather their inability to switch between all three of these modes as appropriate.

            1. 2

              I think the difficulty lies in that the initial discovery of each tribe is met with the revelation of, “ah, I’ve found the way to build software.” Then you sit with it for a few years and start to see the weak spots.

          2. 12

            Agreed. This is an arbitrary distinction and many programmers don’t tend to fall neatly into one category or the other. As a Scheme implementor, I believe “camps” 1 and 2 are not mutually exclusive, and in fact there’s a long history of programming language implementation research that tries to bridge the gap between beautiful mathematical constructs and how to make a machine execute it as fast as possible. In fact, this is the most interesting part of PL implementation!

            1. 3

              not to mention programming language and library design as the user interface you present to other developers.

              1. 4

                Absolutely, that’s more the “craft” or engineering aspect of programming, which fits better in the third “tribe” from the article. You need to be able to work on and balance all three aspects, really :)

            2. 4

              I agree with that. Furthermore, categorizing in general throws away information and that may or may not be suitable depending on the context. Perhaps a better approach would be to identify different traits of programmers and treat each of them as a continuous variable. Based on that it would be possible to categorize less arbitrarily (e.g. by finding clusters in the data). This would be a more data-driven approach and one would obviously need a representative dataset for that.

            3. 11

              No. As an experienced software person, you simply have to divide your time into multiple heads-paces.

              Sometimes you can really appreciate something like this:

              qs([H|T])->qs([X||X<-T,X<H])++[H]++qs([X||X<-T,X>=H]);qs([])->[].
              

              Other times, you might just do lists:sort(A++B), and yet still other times you would be like no you really can get away with lists:merge(A,lists:sort(B)).

              That’s ok. It doesn’t make you alone, but it can be lonely: Most teams in my experience have just one of you, and even in a large company there are likely to be very few of you.

              The article may be written by someone just discovering these different head-spaces exist and jumping to the conclusion that they fit a taxonomy, instead of more like a venn-diagram of considerations that go into implementation and design. That’s unfortunate, but it doesn’t mean there isn’t some good stuff to think about.

              1. 5

                I think this post would make more sense if it focused less on UI and more on shipping things. This would also avoid the awkwardness of writing “Bret Victor” below this:

                How the code interacts with humans is a separate consideration from its implementation. Beautiful code is more important than beautiful UI.

                I think I am personally a bit of all three, naturally trending more towards 1 but trying to be more like 3.

                1. 3

                  Yeah, I had a similar feeling when reading this. I have mostly worked on HPC systems which are used for scientific simulations, and my primary concern is helping scientists do that. I write software in the course of building and maintaining those systems, but if I could make “simulate scientific problems” work without writing any software, I’d do that instead.

                  Or, as a friend of mine put it: computers are just a means, not an end.

                  1. 1

                    Reading this made realize I don’t see myself in any of the 3 groups.

                    I’m glad I came to the comments and saw this as the first line of the first comment. I absolutely feel the same way.