Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three Tribes of Programming (2017)

josephg.com

Post reply on HN
Print view View original

41–50 of 123 posts

Re: Three Tribes of Programming (2017)

#41

Post by bakery2k »

The article claims that most professional software engineers are "makers" - people who build things for other people to use. I would put myself in this category, but I really struggled when I was a professional software engineer because the job seems to be set up for "poets" and "hackers", not for "makers".

Once I've finished building something, as a "maker", I want to be involved in communication with customers and to see how my work is being used. If I've done the hard work of programming something that's useful to others, the reward I need is to see how useful they are finding the thing I've made.

However, for a professional developer the reward for finishing a programming task is just "more programming". I can see how this would appeal to "poets" and "hackers" - it gives them the opportunity to "write more poetry" or "do more hacking" - but not to "makers".

Re: Three Tribes of Programming (2017)

#42

Post by _bxg1 »

I find myself constantly split between camps 1 and 3. Whenever I try and get into game development, #3 pulls me to use Unity, then #1 gets nauseous and has me start writing my own (high-level) game engine, before I just give up.

Rust has been fun because it allows me to indulge in the good parts of #2 without totally losing my sanity. It's not great for #3 though.

I don't think most people fall into just one camp, but these three dimensions make a really useful "personality test" for programmers, and do a good job explaining conflicts like those mentioned by the author.

Re: Three Tribes of Programming (2017)

#43

Post by proverbialbunny »

hinkley wrote: 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 bug would make parts of the internet go down world wide. (Which I did do btw. Sorry.) I both hated and loved that job, but in the end, even in a "bug free" code base, so maintaining it was only feature requests for the most part, I still lost passion over time.

I switched to Data Science, writing code I know will be scrapped. I write mockups to analyze data. It's a lot of fun! But to me it's just running away from the issue.

How did you gain passion for maintaining code bases? If you have a story, it would mean a lot to me. I'd love to hear it.

Re: Three Tribes of Programming (2017)

#44

Post by logfromblammo »

Similarly, I think there are only three versions of software.

Version 1 is what you write fast, to ship it quickly. Corners are cut. It isn't even held together by duct tape and baling wire. It is glued together with bird spit. But it gets the crucial first dollar of revenue. Version 1 is programmed by hackers.

Version 2 is what you write more slowly, painstakingly, to replace version 1 before its innards inevitably spill out onto the pavement. Version 2 is paid for by version 1, but is programmed by the math-poets, the software "engineers". It is very elegant and clean, but doesn't always do what the customer needs. There is zero technical debt. People weep when reading the code, it is so beautiful. But it still doesn't export the management report to Excel yet.

Version 3 is what you get after version 2 has been in production so long that many of the conscious design decisions introduced by forward-thinking architects have been patched out and replaced with simpler things that just work, and are easy to maintain. The ultimate goal of version 3 is to replace itself with a shell script, and then take a nap until a new requirement or feature request comes in. It does everything the business wants, but everything is a massive wad of cruft, and there are legacy bits that no one wants to touch.

The number reported by the software has nothing to do with this. A lot of software never gets out of version 1, or goes straight from 1 to 3, or skips 1 and starts at 2.

Re: Three Tribes of Programming (2017)

#45

Post by sepen77 »

Quekid5 wrote: post #21
hinkley wrote: 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…

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…

In context of this, I've always been thinking that software engineers should be held way more liable -- like those of the physical engineering disciplines. In order to enforce good software engineering practice, there must be either incentives or disincentives (carrot or stick) that have clear consequences on the engineer himself/herself. Otherwise there is nothing stopping them from producing bad work. It may be unintentional and the code perhaps is simply sloppy (but still works).

This is just a thought (and may be unpopular): practices differ wildly from one company to another, and between enterprise software vs hacky side-projecty node apps, nonetheless, maybe it's time to standardize software good practices across the entire industry and enforce them, making them not just "good" practice, but mandatory practice.

Re: Three Tribes of Programming (2017)

#46

Post by pizlonator »

WesternStar wrote: post #25
pizlonator wrote: post #5

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

Instead of thinking of them in nice ways think of the by their pejoratives. Architecture Astronauts, Premature Optimizers and script kiddies. You personally are more of a premature optimizer than an Astronaut. Makes sense that there would be lots of mathematicians and physicists in the optimizers. I'm an Astronaut mostly myself.

Me personally?

I think it’s weird as fuck that you are telling me what I am.

Re: Three Tribes of Programming (2017)

#47

Post by pizlonator »

crimsonalucard wrote: post #8
pizlonator wrote: post #5

I 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 mathema…

To be a mathematician computer programmer, you don’t have to use the Church-Turing mental framework all the time. Sometimes it’s useful and sometimes not.

Re: Three Tribes of Programming (2017)

#48

Post by jandrese »

AnimalMuppet wrote: post #32

> I did a Haskell short course late last year and I challenged the main instructor. I told him "this is all well and good, but I bet I can still make useful software using my practical languages faster than you can". He said no way - using haskell he was convinced he could implement anything I could implement, faster and better and with less code. We didn't test the claim - but I still wonder - is he right? OK, here'…

Seven lines is even a bit much. You could do it all on the commandline if you don't mind a bit of ugliness, and all Perl programmers should be used to some ugliness.

  perl -ne 'if (/^(\d+)/) { print $1, "\n" }'
Put the list of input files at the end of the line.

Re: Three Tribes of Programming (2017)

#49

Post by platz »

mattsfrey wrote: post #23

I take issue with him blanket categorizing Rich Hickey and clojure (spelled closure by him none the less) in the first category along the same lines as haskell. These languages are quite different in almost all respects minus being functional. While the focus of clojure is on simplicity and expressiveness as the author does mention, it was fundamentally created to be a builders language and for getting stuff done fas…

There is a large overlap in ideas between Haskell and Clojure.

You will also find that many of the people who are interested in Clojure are also interested in Haskell and vice-versa.

In fact, they share enough that it causes a tension because it is a little "too close for comfort". i.e. the concepts they share are quite strong, and the concepts they differ are stark by virtue of being polar opposites.

No, they aren't they same along every axis, but they share enough axes that the crossover is quite palatable.

Post reply on HN