Live data from Hacker News

Three Tribes of Programming (2017)

josephg.com

71–80 of 123 posts

Re: Three Tribes of Programming (2017)

#71
post #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 tha…

>I am a maker. I build things for people to use and maintain. So you're dev ops? Jokes aside, do you really have a passion for maintaining projects? This is something I deeply struggle with and any advice on the subject I would be deeply grateful for. I thought I could deal with it and enjoy a project in the long run if it had no bugs, so I worked on some of the code the internet runs on, where even putting in one bu…

> do you really have a passion for maintaining projects?

I don't. I have a passion for clearing roadblocks and that means different things at different times. Sometimes that means automation.

I think you parsed that sentence in a different way than I intended. I think a legitimate handoff is part of building a tool for someone. We have people who run the gamut from rent-seeking to dropping the mic and walking away.

Re: Three Tribes of Programming (2017)

#72
post #2

This 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…

4. Regular expressions.

https://blog.codinghorror.com/regular-expressions-now-you-ha...

Re: Three Tribes of Programming (2017)

#73
post #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 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…

If you don't watch your users struggling with your product then you can tell yourself all sorts of delicious lies about how awesome you are.

If you have no empathy then you can watch them and dismiss it as user stupidity. Which is never an attractive look.

Re: Three Tribes of Programming (2017)

#74

I think this is a good article, but ironically I think all three tribes would actually describe themselves the same way many times (whereas this article implies they'd describe themselves, or what matters to them, differently). To use an example from the article, I think Jonathan Blow would absolutely argue that he wrote his own game engine because it was best for his user . Whether you agree with him or not, he is w…

I think it's dangerous to say, "I don't know much about X, but X clearly wouldn't have worked in this case."

Re: Three Tribes of Programming (2017)

#75
post #21

Earlier quoted context omitted.

At the risk of just jumping on a single point: > I build things for people to use and maintain. Maintenance. Maintenance. Maintenance. That's the key. It is the lack of that mindset which is killing our home world. Ultimately, it's just expression of not having to pay for your externalities. It also kills software dev. If software devs were actually held to account for their legacy (software, hah), then we'd have a l…

What is the deal with maintenance engineers thinking every engineer ought to be one? Can't you agree it takes all types or is there something about maintenance that preempts such thoughts? Edit: Maybe I should go around pretending hackers and poets have the moral high ground.

I think it's contempt for people who won't stand by their work. Maintenance engineer implies a very long term relationship with code but you can't get some self-aggrandizing butterflies to support something they wrote a month ago. The truth should be somewhere in between.

When you're young it's easy to derail your complaints by implying you are not smart enough to appreciate the magnificence of the code. I tend to take Feynman's position that if you're really so great, your solutions will be obvious.

Re: Three Tribes of Programming (2017)

#77
post #2

This 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…

Physics gives us device drivers? ;P

Re: Three Tribes of Programming (2017)

#78

Earlier quoted context omitted.

Eh... As long as the "actually..." only needs a small change to a simple regex (as in your example), perl probably wins the "actually..." game as well until you pull in enough libraries that the Haskell looks a lot like the perl. It's when the regex starts getting overcomplicated and the Haskell breaks out parser combinators that Haskell probably moves into the lead. As you say, though, the margin perl maintains is s…

I think marcosdumay's claim is that Perl is less editable than Haskell. That's arguably true, though I'm not sure that editing a simple regexp in a simple script actually shows the issue.

Yeah, I agree with the broader claim. IMO well-structured Haskell will tend to be easier to maintain then well-structured Perl, and poorly structured Haskell will tend to be easier to get well structured than poorly structured Perl.

I just thought the express claim being made significantly oversold it. Whichever approach you take with the Haskell in the example under discussion, modifying the Haskell is not easier than adding a handful of characters to a simple regex.

Re: Three Tribes of Programming (2017)

#79
I'm clearly primarily a maker: I make applications for users, mostly websites, and I care about them being easy to use and useful to the user. I also care about easy of maintenance, and therefore about clean code.

I notice I do strongly identify with the Poet/Mathematician, I'm just not one in practice. I do love elegant code, algorithms, data structures, code that's concise, logical and easy to read. I love that many programming languages have become more functional. I wish I could do a project in Scala. I wish I understood Lisp.

In the end, though, I don't care as much as the real Math/Poet. I don't care for Scala's over-the-top Turing-complete type system. I don't care for proof of correctness. I care that my code works and looks good and is easy to maintain, and joyful to work with, and those are practical matters for makers.

I also appreciate the work of hackers, but mostly because their compilers and VMs and OSs make it so I don't have to worry about those things. I've programmed in C, but I love not having to worry about memory allocation anymore. I want my algorithms to be efficient, but I don't pretend I can reinvent an existing algorithm and implement it better than the standard library has already done for me.

So I don't see the strife, I see different roles. Makers make the end-user applications, but to do so, they use languages and programming principles designed or influenced by the Math/Poets, and they run on efficient and secure platforms built by hackers.

We need each other.

Re: Three Tribes of Programming (2017)

#80
post #7

Good 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.

> People who love Haskell, lisp, etc. despise Ada.

I guess I'm not a person, then? All three are great languages. (Well, language families, in the case of Lisp.)

Post reply on HN