I like this breakdown. I want to make a radar diagram of my personal weighting of these three groups, and put it on my resume. I think, something like 75-15-10.
Three Tribes of Programming (2017)
11–20 of 123 posts
Re: Three Tribes of Programming (2017)
#12I don't know all of the examples cited, but bringing up Bret Victor in the sentence immediate following "Beautiful code is more important than beautiful UI" surprised me.
Up and Down the Ladder of Abstraction is still one of my favorite examples of an interactive webpage, and is beautifully elegant in how it integrates with and supports the text.
http://worrydream.com/LadderOfAbstraction/
It's cleanly designed as does exactly what it needs to. Hard to beat, IMO.
Re: Three Tribes of Programming (2017)
#13Bret Victor seems badly miscategorized. He obviously cares more about people than code and validates his ideas with prototypes written in javascript. I would place him squarely in tribe 3.
Re: Three Tribes of Programming (2017)
#14Most people are makers and hackers.
The poet is a rarity.
I work in a golang shop and when I tell people that json and unions are hard to work with in GoLang because it's missing an essential part of the poem (the coproduct) I get blank stares. Not one person knows what I'm talking about.
I think of it as the next level. Everyone starts off as a maker or a hacker, then if or when you get really good you discover the poetry behind all of it. Most people don't ever get that good though. All they are concerned about is the next implementation detail
Re: Three Tribes of Programming (2017)
#15This is simplistic. There's way too many tribes. Programming has embedded itself into tons of domains. x Hacker is the number of tribes that we have. Language Hacker, Security Hacker, Frontend Hacker, Ad Tech Hacker ....
The tribes describe domains within programming devoid of external details. Security, UI and ads are external as these can be applicable on things outside of programming.
Re: Three Tribes of Programming (2017)
#16This is fantastic and surprisingly close to how I tended to explain computer science to students and graduates: In Computer Science, there are 3 kinds of problems: 1. The problems that Math gives you: algorithms, data structures. These are the problems you think you're going to solve and sometimes you do, but often we just need a few really smart programmers to solve this and the rest of us can just use those solutio…
I'm continually surprised at how quickly non-technical problems come to dominate my time on a software project. E.g. my code doesn't work because two business stakeholders have slightly different, irreconcilable notions of what a "customer" is and it has to satisfy both.
Re: Three Tribes of Programming (2017)
#17This type of article is like politically targeting citizens, their purpose is not to unite but divide...
Hack, I started as a FE intern in Amazon, originated Amazon Kinesis, built tools for managing google's data center network software, Borg core and user library, and now other stuff.
My work as a programmer constantly change. Am I in any tribe then?...
Re: Three Tribes of Programming (2017)
#18> You are a maker. You build things for people to use I am a maker. I build things for people to use and maintain . This puts me at endless odds with the hackers. All three groups suffer from Novelty Seeking and Risk Taking (aka Adrenaline Junkies), but the hackers seem to get it the worst. My hatred of tools that fall apart the third time you use them goes back to childhood. I don't want to put my name on any of tha…
hard agree. I remember once coming across a 3rd party web API whose documentation stated you could configure something like 50+ settings with it. Only about half of them actually changed the configuration, the other half I had to actively go in and start doing things like shutting down the service, updating various files, and then restarting. When I realized this I just thought to myself, how in the world does your p…
Openssh server and client are included in windows 10 as an optional feature for a while already.
Re: Three Tribes of Programming (2017)
#19This is fantastic and surprisingly close to how I tended to explain computer science to students and graduates: In Computer Science, there are 3 kinds of problems: 1. The problems that Math gives you: algorithms, data structures. These are the problems you think you're going to solve and sometimes you do, but often we just need a few really smart programmers to solve this and the rest of us can just use those solutio…
Makers who don’t understand 1 or 2 often create slow or insecure code that often results in clear user impact.
For example, I’ve seen diffing / recomputation code operating in O(n^3) or O(n^2) where O(n) or O(1) is possible and necessary for reasonable performance. I’ve also seen extremely poor use of network requests (multiple serial requests) that happen because the developer doesn’t understand network latency and networking performance (in this case with a single data center in the world).
Re: Three Tribes of Programming (2017)
#20I apparently fall into the latter tribe and feel the need to justify myself, so begin rant!
There may need to be a fourth tribe? I write my programs to accomplish tasks for the user, but I use tribe A and tribe B languages to get there as they make the computer 'smarter' while I'm designing and coding.
My programs should encapsulate and execute whatever work needs to be done as quickly, safely, and correctly as possible so the user can get on with their day. After all, programs exist to accomplish tasks for people, whether directly (my app code) or indirectly (memory allocators).
I try to design/code for the scenario of a new user who knows logically what task they want to accomplish, but not how to get the computer to do that task. My programs should guide the user like a travel map. You are here, you want to go there, and you need to do the following things to do so.
This means if they are missing or have malformed input, I tell them what input they are missing and what the program expects it to look like, along with trimming leading/trailing spaces.
Nobody likes a picky program, like the accounting system running on that one AS/400 in the basement that MUST have a CSV with exactly 15 columns and no more than 32 characters per column (and don't even think about using commas anywhere) or the whole thing silently fails after 12 hours.
As the user learns how the program works, they don't see/need the guides any longer as they know more and more of what they are doing. They want to speed up. Binding keyboard shortcuts to every menu option enables advanced users to breeze through the program from muscle memory.
So what languages do the mythical fourth-tribers use, those who are fine with standard libraries and not sorting binary trees, but don't countenance Electron web bloat or ever-vanishing discover-ability/accessibility/readability sacrificed on the altar of 'mobile first design'? Over the next 3 years, I plan to learn the following high, medium, and low-level languages so I can be productive in each domain, that way wherever my users are, I can empower them to rule their machines like a boss.
F# is great because of features like pattern matching, static types, and immutability, which all combine to uphold the 'pit of success'. Other languages tend to uphold 'check it all at runtime, cause I won't check it for you'.
Rust is a low-level language without the apparently rampant memory leaking remote code execution undefined behaviors of C or C++. Writing secure C or C++ code is just about impossible for experts, let alone curious beginners like myself, so why even bother? Rust it is.
Due to its trendiness (okay, more like more active community) Golang just took over Free Pascal for my next up middle level language. It sits between native low-level Rust, and JIT high-level F#, and it features easy parallelization and has just one or two ways of doing things, reducing code complexity.
Free Pascal and Erlang are on the list too for historical and always-stable-forever reasons, respectively.