Tribes of Programming (2017) | Hacker News Reader

Tribes of Programming (2017)

josephg.com

134 pointsmyth_drannon57 comments

I'm just skilled labor.

I'm a milling machine operator, except instead of a CNC machine making, idk, table legs, I'm writing a thing to filter some database result based on some user input from a web page.

I am not doing poetry or making hardware dance, I am not doing mathematics (directly anyway). This is a trade. I'm building the small pieces of the bigger things our culture either needs, or sometimes just wants. It's my job and I'm good enough at it that I've gone from almost literal apprentice to lead. I'll work hard, then retire to a farm and never touch another keyboard again.

(jk how else would I do my taxes, I'm not a luddite)

So that's whatever "tribe" I am, I guess.

I think what you describe is captured fairly well by the third "tribe":

> The way people in this camp describe themselves is fundamentally pragmatic. They write software because software is useful to other people [...] I think most professional software engineers are in this tribe

Fwiw, I don't think "tribe" is a good word for what the author describes. Maybe "attitude" or "principle" would be more fitting, albeit less catchy and intriguing.

I don't like the term tribe either. To me, these are biases. And biases can change or be context-sensitive. I find myself in 1 and/or 3 often depending on the work.

I don't think what he described is captured at all by the third "tribe." He clearly does it for money and there should be a fourth "tribe" for that category. I agree with you that "tribe" is a poor choice here.

I really wish there was a professional organization or - dare I say it! - a union which represented this point of view of SWE. I like what I do but I hate how much of work and tech culture creeps into your life, as though it's the end all and be all of one's existence. No one expects plumbers, welders, or civil engineers to be making drainage systems in their spare time.

There is the principal difference, which is well seen in how software engineers compare to all other sorts of engineers (less so today, as apparently all engineers now are a little software engineers).

Plumbers, welders and civil engineers are supposedly trained in their area and know well how to solve a pretty well defined set of problems. Much better defined than a similar set for software engineers. So for plumbers "execution" is paramount, not - mostly not - the creative side of designing. While software is bigger, more vague and with less clear-cut recipes area.

This is less and less true lately - last couple of decades in particular - as more and more software engineers are actual plumbers in this sense. Those don't make drainage systems - or, write program - in their spare time - they take photos, sing or enjoy woodworking. Even though their employers seek people who'd program in spare time.

Those who do - there are plenty of those who enjoy programming more than just to make it a profession - can be attributed to first or second group. I think the third group actually has plenty of them as well. They don't need to think of technology to be all, end all of one's existence - they just enjoy programming, and doing little, or pretty big (this is harder, so has a lesser chance) work pieces for people. But they don't necessarily not programming on weekends.

Are there any skilled workers - whether plumbers, welders, carpenters, lawyers, accountants, doctors, pilots, or programmers - who immediately stop thinking about, keeping up with, or otherwise expressing an interest their field after clocking out for the day?

Some more than others. But few, it seems.

I have a friend who is married to a carpenter, and she says absolutely nothing in the house gets fixed, because he's done with work when he gets home, but doesn't want to pay someone else to do something he could do.

There is, just not in every country.

https://www.ordemengenheiros.pt/pt/a-ordem/colegios-e-especi...

https://www.ingenieurwesen-studieren.de/studienwahl/abschlue...

Usage of Google translate is left as exercise.

I came to the comment section looking for the mercenaries like you, knowing I'd find them, because I knew it was by far the largest group and oddly omitted from the article.

> We self-select into communities of our peers based on these ideals. We use coded language to express these ideals to our peers.

But, maybe most of us actually _don't_do this. We all know of the annoying fetishization of "passion" in programming that alienates the majority and it's getting weirder and weirder to keep ignoring it in the real world.

Tribalism be damned, deep down, most of us are doing this because it's a pretty fun way to keep our families fed and our minds occupied.

People who write about programming in their spare time are people who really like programming. You aren't going to read a blog post by a software 'mercenary' describing their tribe because mercenaries don't work for free.

There are many people in all sorts of 'tribes', but only a few of the tribes wrote blogs.

Yeah, I see plenty of articles on either side of the extreme (that obnoxious "Programming sucks" post comes to mind).

You have a great point. The large mercenary class in the industry is just not as visible because the nature of it creates a non-vocal majority.

Actually, I'm a developer from the second camp:

  I am a hacker. I make hardware dance to my tune.

Why? First of all I enjoy doing things. Understanding the computer, the compiler, how to make use of it more, how to extract more performance from my code while being absolutely correct is making me extremely happy. I feel accomplished. I also apply this knowledge in some scientific applications so, they're not all lost.

OTOH, I don't throw eggs to other so-called tribes or the mercenaries, because We're humans and we're different. We have different reasons. I live in this stuff since C64. Not everyone has to. Some likes poetry, others don't. Some listen to classical, others listen to death metal, rap, whatever. I don't expect everyone to like, understand or endorse what I do. The correct baseline is we're expressing ourselves here, including the mercenaries.

So, as long as you don't throw eggs at me, we're friends. I'd gladly help you with my knowledge and more importantly, I want to learn from you to broaden my horizon and augment my ideas with yours to try, see and do new things.

Tribalism is not inherently bad, the quiet war and fetishization of these tribes are the toxic parts of it. Similarly, being passionate about programming sans the zealotism is not harmful IMHO.

These camps provide a nice foundation and philosophy when used correctly. OTOH, I agree that this is a double edged sword and very sharp one indeed.

Why not discuss further?

Sure, that's good and all makes sense. I am somewhere in the middle of a venn diagram that includes all these tribes, plus mercenaries and many other things that aren't described, as I'm sure many of us are.

I do think it should be discussed further but my original point was that we may be missing out on discussing the unseen majority as much as we do these passionate ones.

Then again, perhaps those groups are just not as worth discussing other than in side notes like these HN comments and that's just fine too.

The author probably underestimates the limitations of Unity, especially earlier versions from back when The Witness was made. It would kind of be surprising if all the things in that game were possible to do with reasonable performance in Unity back then, especially without paying ~50k+ for source access.

It feels like the article almost but doesn't quite touch on it: there's people firmly in multiple camps, and gamedev tends to be camp 3, but also very often camp 2 and/or camp 1.

To get AAA or even AA games running requires a lot of dogma from camp 2. Graphics programming, procedural generation, and gameplay systems complex enough to produce emergent gameplay would be camp 1 from the sounds of it.

I feel my feet firmly stuck in all 3, at any rate.

Having been part of demoscene and still having a feet in game dev scene, dogma is exactly the right word to describe it.

Game development appears to only move forward when some console or OS vendor steps in that asserts "this is how we are going to do it now".

It happened when moving from Assembly into high level languages, adopting C++ despite all its bloat (vs C/Pascal/Modula-2) thanks Watcom, PS SDK and DirectX, Objective-C/Swift (thanks Apple), C# (thanks Unity, Managed DX, XNA/WP 7,...).

If one of the big names in consoles would release a WebGL/WebAssembly based games console, with a couple of first party titles that would show its potential, Mario or whatever, we would see a couple of studios running to get a place on their store.

I work at a small company on a single page webapp. Since we're working on a subscription-based product, we need to focus on fixing bugs and improving usability to make our users more productive and more happy. This should place us in firmly the third camp of pragmatic professional software engineers. But I don't agree with the trichotomy outlined in the article.

We spend plenty of time and effort doing "programming as hardware hacking" to implement a backend that can process our customers' data orders of magnitude faster than our closest competitors: This allows our customers to obtain analysis results in minutes/hours instead of days/weeks. We didn't get there with the third-camp sentiment that "The program only has to be fast enough for the users" - if we did, we wouldn't be leaders of the (niche) industry that our customers operate within.

Then again, we spend plenty of time doing "programming as applied mathematics". Our software inherently consists of a lot of geometric algorithms. To give a recent example, a couple colleagues and I spent a couple days last month to fix a buggy geometric primitive: Given an almost-simple polygon, which is made by joining the endpoints of a polyline without self-intersections with a straight edge, compute its area. We had a seemingly-correct, but complicated and evidently buggy, implementation that needed to be used in a new user-facing feature (contour-line simplification). After several whiteboard sessions and do-overs, we found a simple formulation of the problem that admitted a simple and obviously correct implementation. The buggy area computation didn't cause any crashes or other obstructions to the user, but it created results that looked aesthetically unpleasing (because the lines were poorly simplified).

I'd say most consumer software falls in the third category, including yours.

"Fast enough for the users" is apparently, in your case, "fast enough to give you competitive edge."

Your wonky polygon was apparently a bug with sufficient impact to not make the program act in the way the users expected it to. Aesthetics and UI is really important to a lot of users.

My hero in this regard is Erik Meijer who went to Microsoft purposefully to bring Haskell concepts to .NET as he recounts in "Confessions of a Used language Salesman: Getting the Masses Hooked on Haskell" (2010) [1] He put async/await in Dart after working on it in C#, a feature I really appreciate. From my limited understanding and I hope someone will correct me, it is a continuation monad. Everything I know about monads comes from "Explain Monads Like I'm five" by Theofanis Despoudis [2]

"After failing to sell solving real world problems to the Haskell community, as well as failing to sell Haskell to the real world, I started to wonder whether pushing for pure functional languages was actually the right strategy. Maybe I thought, I should sell my soul to the most popular programming paradigm, objects, and to the company that has the biggest market share, Microsoft...

My main reason to join Microsoft as the company to infuse mainstream programming languages with monads and other functional programming features was that I believed the quickest road to success would be to work on adding support for exotic language features to the new Common Language Runtime..."

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72....

[2] https://dev.to/theodesp/explain-monads-like-im-five

> From my limited understanding and I hope someone will correct me, it is a continuation monad. Everything I know about monads comes from "Explain Monads Like I'm five" by Theofanis Despoudis [2]

Futures/promises do form a monad. async/await is not a monad since async and await are not values, functions, or anything really. If they're implemented on top of futures/promises then async/await are like a hamstrung version of do notation that only works for one particular monad.

Also async/await is not really full continuations, it's a very restricted subset of continuations (which is good, full continuations are incomprehensible).

Thank you. I was including futures promises in my mention of async/await because that's how I use them mostly. I couldn't remember where I got some confirmation about my understanding, but since found it in my bookmarks. It seems to me that Haskell programmers want to abstract away the machine and this makes me wonder how well this works with practical concerns of controlling the computer to make it work. I look forward to learning more:

"async/await is just the do-notation of the Promise monad" https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb...

Haskell programmers generally believe in making it clear what the code means and letting the compiler/runtime figure out the details of how to execute it. A perfect programmer with infinite time could almost certainly get more optimal behaviour by specifying all the details; on the other hand, a language that expects the programmer to specify all the details gives them plenty of opportunity to get those details wrong, or for their choices to become outdated.

In my experience Haskell significantly outperforms C++ on real-world business problems with realistic development effort (as opposed to carefully tuned microbenchmarks). I do think laziness was a mistake (to the point that one of the biggest industrial deployments uses a strict variant instead). I've spent most of my career doing work in Scala that's very much real-world, so as far as I'm concerned all the people talking about these things being academic or overly abstract are talking crap - I use this stuff every day, and whenever I've tried to take a shortcut (e.g. define a slightly law-breaking monad instance, abuse some mutable state somewhere) I've come to regret it later.

I think the tribe that is missing is the pop writer (or educator?): the programmer who wants to make programming as easy as possible for themselves and everybody else. The pop writer is different from the poet. Poets don't shy away from difficulty if it repays the reader's effort in some way. Poetry can even be interesting because it says or demonstrates something interesting about poetry itself. (Code where people entertain themselves by solving simple problems in elaborate ways could fall into this category.) That's not what I shoot for. When somebody reads my code, I want them to think, "This is easy; any idiot could have done this." My idea of a heroic achievement in software, which I've seen done but have only done in small, partial ways myself, is when a programmer tackles a really knotty problem that has been stumping their colleagues and comes up with a solution so simple that after seeing it, they can no longer understand why they used to think it was a hard problem.

Don't know if the "joke" originated with Abelson and Sussman but here's Hal Abelson talking about it: https://www.youtube.com/v/-J_xL4IGhJA

"It's not about computers in the same sense that physics is not really about particle accelerators."

I sort of agree, but I guess it depends on what we mean about computer science being about computers. We can do things now that were downright impossible when A&S recorded their Lisp lectures simply because we can think differently about what's reasonable with regards to time and space complexity. And, of course, Abelson himself jokes about everyone wanting a faster computer in a later lecture.

Perhaps we're simply confusing CS with software development, which I suppose could be likened to confusing mathematics with accounting.

I don’t think the distinction is necessarily unique to software.

To run with the physics/particle accelerators analogy, someone still has to build and run CERN, and plenty of talent is needed to make CERN possible, many of whom are probably physicists of a different “tribe”.

We may all learn similar fundamentals and take different views on the “right way” to look at our craft, but for better or worse we’re tied together by shared knowledge.

> Perhaps we're simply confusing CS with software development, which I suppose could be likened to confusing mathematics with accounting.

I think the confusion stems from the amazingly vocal community of people who claim how a degree in CS (whichever level) made them amazingly better at software development/engineering.

I can imagine how a CS degree can help you with pure functional programing, or with designing distributed systems.

> "I can't help but feel that this place [programming as a tool to make things] is a touch soulless."

I was somewhat interested until this gem, but then he lost me.

But I realize they're artificial categories; you can both appreciate elegant code while feeling satisfied with a useful creation. You can weep with joy over speed and efficiency while loving the delight someone has in using what you've made.

And really, this essay quickly becomes another 'there are real computer scientists, and there are the others', and I'm so done with that shit.

Tell me how you measure your programming work (O(), $, bytes, Tflop) and whether or not you divide it by time and I'll have a pretty good guess at your tribal affiliation.

I measure it by how useful it is... none of your 4 criteria.

Are your measurements using numbers?

I think $/time is a pretty good proxy (definition?) for usefulness

I find it rather disturbing (if not just cringeworthy) especially when the classification is vague enough that almost everyone can be classified into more than 2 categories. I always have this feeling that if you classify yourself like "oh yeah I'm this kind of person" it'll harm you in one way or another. Yes sometimes these kinds of stuff could be fun and all, but still.

Maybe it's just meaningless to classify. Maybe it's just me, idk.

As long as you realize that there are more ways than one to slice a cake then classifications are useful. The slicing is always(?) relative to some implicit or expressed goal, which may vary depending on circumstance. Generally, we as humans would not survive in our daily lives without our classifications.

But it can also lead astray, for example when less important categorizations occupy a space that is better served by more comprehensive and valid (not to mention empirically supported) classifications. I would put the linked article in this category, to some extent.

As for the problem of vagueness: classification that only contains mutually exclusive categories carry the least cognitive load, but this is seldom realistic especially when classifying human behavior. That said, properly classifying humans is messy, and also risky as human differences tend to trigger emotionally value-lade comparisons. It is a popular pastime, but usually leads to rot of some kind or other.

Really enjoyed the article. It's well written and makes it's point succinctly.

Though no true trichotomies exist, this one approximates the landscape nicely (in my opinion).

I'm a whore. I write code for money.

I would say everyone I know in big tech fits into this camp.

A whore? In the sense of prostitution? Time for money? Or money at the cost of your integrity? Real curious.

I would say time for money, as I don't really have any programming "ideals". I don't really like programming and I don't really hate programming. However, I am not going to make a seven figure income doing something else, so I will be programming until I stop :)

You make 7 figures income and programming is nothing more than a job for you? Where do you work?

What about the "This is all I'm good at, and I just do it to get paid" tribe?

It's a subset of the "This is all I do, and I just do it to get paid" tribe.

"Mercenary" would fit this.

Should I be worried that I identify with each and every of those three camps?

Depending on the project at hand - and perhaps also depending on the day - I am any one of the three?

My one extra nuance would be the "less is more" attitude rooted in UNIX tradition.

No, that sounds like basic maturity. Knowing when to value the things each camp values, and when NOT to do so, is important.

Everyone in this thread seems to identify more with camp 3. I'm very camp 2, I don't care about making anything, most of my programming is means-to-an-end, little scripts and cli binaries, rarely any large projects.

I see a computer as a sort of huge warehouse-sized machine, with tiny little gears and pistons all moving in perfect timing, and I just want to throw an apple into it, to see what happens.

Nothing exists in a vacuum. Same here, and you could rank these "tribes" by relevance: #3 as thoroughly intertwined with the real world, #2 as useful but mostly disconnected, and #1 as irrelevant for everyone but themselves (and ironically, holding themselves in the highest regard).

This almost reads like stages of individual maturity -- from "only aware of self", through "able to manipulate the outside world to reach goals", to "aware of and collaborating with others for common good".

I'm firmly in the #1 camp but I have plenty of respect for people that can actually get useful things done.

I am quite firmly in the #3 camp and I have a lot of respect for #1.

> #1 as irrelevant for everyone but themselves

I assume you then don't use the following features?

- GC

- Generics

- Higher-order functions

- Recursion

- Static scope (oh man)

- Type inference

- Lambdas, closures, ...

Take a look at [1] to see why FP might be useful. You'll be surprised how many interesting features they have, and will want some of those in your current OOP-focused language too

[1] https://www.coursera.org/learn/programming-languages/

This lines up remarkably well with something I've thought about myself. People often argue about what the "best" first programming languages to learn is. I think it depends on what your goals or interests are:

1. Interested in math and computer science? Start with Scheme. 2. Want to be an engineer? Start with C. 3. Want to develop a product (or just general interest)? Learn Python.

These categories line up precisely with the article's three tribes: Mathematician/poet, hacker, and maker.

Good advice. My response is generally "the one you're going to write something in". Only if I have time for a indeterminate length conversation about what they'd like to do to get started, of course!

I make things for people... and if the tools don't work right, then I persistence hunt down the bugs and make the technology bend to my will.

The computer is not an object of worship... it is a tool users must deal with to get their jobs done... that tool should reliably and predictably work with as minimal fuss on their part as possible.

My language of choice is Lazarus/Free Pascal, but I'll do whatever is required to get the job done.

I‘m ultimately in camp three, trying my best to learn from camp one, adhering to camp two when needed.

Past comments: https://news.ycombinator.com/item?id=20882783

This article always resonates with me a lot, since I'm pretty definitely part of tribe three but constantly feel inferior to members of the other two tribes.

Maybe the feeling of inferiority is really just an appreciation for the contributions of the other "tribes", which I'd argue makes you able to "cross tribal lines"

I'm firmly in tribe 2. Programming for its own sake. Having tribe 1 and tribe 3 would be nice but not necessary :)

False trichotomy? A good piece of software is a combination of getting the job done, elegantly and efficiently?

Reply on news.ycombinator.com