Three Tribes of Programming (2017)
josephg.com
Three Tribes of Programming (2017)
1–10 of 123 posts
Re: Three Tribes of Programming (2017)
#2This 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 solutions.
2. The problems that Physics gives you: hardware, device drivers, network latency. Sometimes you do systems programming and work close to the hardware. But once again, once one engineer has solved this, most of the time we can just use those solutions.
3. The problems that other engineers give you.
And that is where you're likely to spend most of your time: gluing APIs together, reading code and documentation, and arguing about code formatting.
This is why in so many ways computer science is a social science. Certainly "software engineering" is. Everything you do is going to be about communication. When you write code, you're not just communicating with the compiler and the machine, you're communicating with other engineers. You're going have to craft smart documents, emails and collaborate. Any nontrivial solution will require these skills, so you better start investing in them.
Re: Three Tribes of Programming (2017)
#3> 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 that shit.
And yet...
I'm also quite comfortable and capable performing emergency field repairs on objects real or virtual. I think the difference is I know this is temporary. Single use. When we get back to where there are tools and supplies, we should take it apart and fix it for real. The hacker declares victory and moves on to the next problem.
Where I disagree with the breakdown here is that the makers are also poets. It's just that the medium is different, so it's hard to compare. I think it's safe to assume that the same is true of the hackers.
Re: Three Tribes of Programming (2017)
#4This 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 ....
Re: Three Tribes of Programming (2017)
#5I don’t buy this.
I am a mathematician who makes things and uses math to understand how the code executes. Execution is not an implementation detail to me.
Re: Three Tribes of Programming (2017)
#6This 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…
Joel Spolsky talks in an interview about how his bookshelf shifted from 80% theoretical books to 60% psychology books over the course of his career.
Re: Three Tribes of Programming (2017)
#7Good article, though Ada is misplaced there. It is more of a maker’s language. It just has a formal proving add on (SPARK) available to test correctness because of its use in mission critical software where correctness really really matters. People who love Haskell, lisp, etc. despise Ada.
Re: Three Tribes of Programming (2017)
#8I don’t buy this. I am a mathematician who makes things and uses math to understand how the code executes. Execution is not an implementation detail to me.
It is an implementation detail when you go to the extreme. Most people are not segmented this rigidly though so of course they worry about execution as well as the high level mathematics. But most of the high level math and designs give a high level view of everything.
Category theory and type theory don't fit cleanly with assembly language (the implementation detail).
Additionally at the very fundamentals of mathematical CS: the Church–Turing thesis doesn't describe anything about the real world. It says that the implementation of a true lambda machine vs. a turing machine are essentially the same thing, the thesis does not describe how it's basically impossible or extremely hard to build a true lambda machine.
Re: Three Tribes of Programming (2017)
#9This 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 agree with your three problems, but only if problems means hard roadblocks to achieving your goal.
Much of programming is encoding what you want to computer to achieve and is therefore a rather long process, but not necessarily hard. Precisely specifying how a GUI should look has a substantial amount of necessary complexity, and writing that out doesn't fall into 1, 2 or 3.
Re: Three Tribes of Programming (2017)
#10> 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 pride as a developer even ALLOW you to ship something that bad.
Another example is PoSH (Powershell SSH). The author just randomly changed how he does things, and changed the defaults, so one day things that worked before just stopped. You now had to configure it to have the old behavior. WHY!?!
Then I realized that if you issue a shutdown command over SSH via PoSH it would hang until the timeout was hit. I then found myself maintaining a custom version of PoSH to work around the issue. I even went as far as to describe the issue, and my fix, for the author, but to this day I don't think they ever actually fixed it. The day when we can natively use SSH from powershell can't come fast enough.
The point being that things are always so damned brittle. And the worst part is that I don't think it gets better the lower down the stack you get. I've ran into plenty of these types of issues in C and C++, it's a mindset and it drives me nuts.