The Next Big Blue-Collar Job is Coding

[Paul Tarvydas]

https://www.wired.com/2017/02/programming-is-the-new-blue-collar-job/

[Paul Morrison]

And, of course, this is even more true with FBP - I'm not joking!   Just as FBP models a data factory, so FBP application design teams will have both the people who design the data flows within the factory, and the people who design and build the machines that actually transform the data.  We need to get FBP into the schools... early!

On Fri, Feb 10, 2017 at 12:53 PM, Paul Tarvydas <paulta...@gmail.com> wrote:

https://www.wired.com/2017/02/programming-is-the-new-blue-collar-job/

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[timtheli0n]

Dear Paul,

I really don't see the idea of having a two class society of programmers as being a good thing, though this distinction is already developing with the creation of "dev ops" and such. Whom would FBPs property of promoting a class division among programmers help? I don't see it as being being a good thing for anyone but large companies. It is certainly not a good thing for us programmers. Back in the days of Microsoft Avalon, before Windows Vista came out, Microsoft was very much aiming for a devision of labor among three groups. Designers would create graphical user interfaces using the XAML language, Architects, would draw UML like class diagrams and database schmas, and code monkeys would fill in class templates which were generated by the first two groups. Obviously, this doesn't work with OOP, and maybe (I don't know how they programmed internally) this was what lead to Microsoft falling apart in those years. But there are other models that CAN lead to a class division. Take Haskell, as an example. A strongly typed, purely functional programming language. It is actually possible to have an architect write a set of type definitions and specifications for functions, and a bunch of code monkeys fill them in. Do you want to be a code monkey? I don't. Is that why you are suggesting that we get FBP into the schools early? In order to prevent people from becoming code monkeys? I don't see how that would help. Afterall, someone is going to have to become a code monkey. More schooling doesn't prevent a lower class in a class based society. The proportion of low class to high class individuals doesn't change with schooling, it only makes it so that there is more competition to get into the higher class. Technology CAN change the class composition, but education really cannot. The claim of western capitalists has been that, as technology advances, lower class jobs will be replaced by robots and more people will be able to enjoy upper class creative positions. With your proposed division of labor in computer science, this trend would reverse and the vision of a highly educated classless techno-utopia becomes no more than a scam to get us to get into more college debt! I don't want that. I don't think that anyone who isn't either evil, or a megalomaniac who hopes he/she will be at the top wants that.

I understand that many are megalomaniacs. They dream of being "the architect" the wizard with the pen, wo sets 1000 code monkeys to work with a stroke of their pen against the whiteboard. Live programming with nothing but a wand, drawing FBP diagrams freehand, having a secretary or ten to interpret them, all of those fiddly cody bits being worked out by some Indians in the basement. I TOO would love to feel that way. Imagine anything, draw the diagram, and if my architecture didn't suck, watch the blocks fall into place and the invention form before my eyes, take credit for the work of thousands, like a certain Steve Jobs. But if I were to be able to rise to the top of such a hierarchy, to be the god emperor, it would not be right to those below me.

And the likelihood is, anyways, that I would be among those in the basement, cursing over a contorted algorithm which could just barely fit into the schema that the architect had devised. Telling myself that the shoddiness of my own code was only the result of a poor design at the top. Telling myself I could do better, and never knowing if I could.

However, the same technology of FBP could lead to a radically different outcome. It could mean that us programmers could become independent trades people, like the cobblers or carpenters of old. Each programmer would have their own shop selling widgets, occasionally being asked to assemble a set of widgets into a program. Indeed, FBP could free us from the need for large software firms, because the same project that would take a team of software engineers years to make, could be assembled by a single individual, from parts which were traded between equals. It would not be a hierarchical society, but a society of independent laborers. A society dominated by a petite bourgeoisie with no need for anyone at the bottom except those youth who sweep the floor until they've gained the skills to set up their own place somewhere. We could imagine a society in which "small business Republican" meant something other than "dirty corrupt scumbag who hates gays".

But in order to aim for such a goal, we need something other than mere education. We need to approach the development with the right mindset and most importantly, with our own free and individual spirit which condemns such hierarchical structures of labor and aims for a more Proudhonian society of truly free and equal engagement between individuals.

Regards,

Timothy Hobbs

[Paul Morrison]

Hi Tim,

I believe I was predicting an application development society more similar to your penultimate paragraph - maybe I didn't express myself too well!  I have always said that FBP programs are "bossless", and I don't think a lower class of "code monkeys" fits in with that vision.

I really don't like the term "code monkey", and I have always believed FBP will eventually remove the necessity for this kind of work.  The ideal of FBP is that most applications can be constructed by drawing diagrams - using something like DrawFBP, with a whiteboard only being used in the early stages, if at all - with only a few new components needing to be constructed. 

Not being too familiar with factory assembly lines, I based some of these ideas on my experience with Unit Record systems in the early '60s, where you worked with the machines that were available - but each machine had quite a lot of potential for customization using plugboards - in FBP I call it "parametrization"...  In FBP, you also have the potential for constructing new "machines", but this should become less and less necessary, except where you are moving into new application areas.  And it is definitely a different skill from application design.

I obviously didn't express myself clearly.  I see FBP as more of an engineering discipline - no "code monkeys" needed.  In my book I say that you don't give an engineer a pile of girders and a manual and tell him/her to go build a bridge - there is a long period of training and gaining experience - but we do that all the time with conventional languages.  This is why I said "we need to get FBP into the schools early" - it's a truism that the first language one learns affects one's mindset - possibly for life!  I want the kids to get exposed to FBP ideas early, so that they have as little unlearning to do as possible, to make the paradigm shift to FBP.  Our experience with our first FBP implementation was that the people who had the most trouble were programmers with 5-10 years of experience: trainee programmers had much less trouble, and FBP also provides a good communication vehicle between the other roles involved in development of an application (management, operations, etc.)..

I could probably go on... but this is all in my book, and various papers I have written, so I am bit surprised at your earlier paragraphs - it seems rather a joyless vision!  In my book, I used the analogy of game builders and game players - two different skills, but I wouldn't call them a two-class society.  Do you feel this wouldn't work in the programming world?

Regards,

Paul M.