human code

human

function poobah(path){
good.see(observer)
good.do(tiger)
good.help(apprentice)
good.helpAnother(legaldocumentassistant)
good.helpHelpers(licensed)
good.steer(captain)
good.build(EPWA)
good.rethink(iii)
good.toggle(0)
};

START
Borrowed&Changed from: http://read.humanjavascript.com/ch01-introduction.html
Human JavaScript: EDITS IN BOLD
Code is as much about people as it is about computers. Sure, it's run by computers, but it's written by, maintained by, and ultimately created for people. People are not computers. We are not robots. We are unpredictable, flawed, and irrational. The same people with the same tools and instructions won't produce the same output each time. We generally don't like being alone and we don't work well in isolation. In fact, in order to do our best work we need to work with other people. None of these traits are bad things, quite the opposite. They're what makes us who we are, they make us, well... human. Yet, as developers it's easy for us to get so focused on optimizing for technology that we forget to optimize for people.

You can read about JavaScript, the language, elsewhere. Its good parts, bad parts, and ugly parts are well documented. This is a book about a specific set of tools, patterns, and approaches that we feel are optimized for people. These approaches enable our team to quickly build and deliver high-quality PUBLICWORKS for humans.

... patterns start to emerge. Patterns that enable us to efficiently ACTIVATE PUBLICWORKS (with real-life deadlines) as a team.

As we've gone along, we've done our best to extract reusable tools out of them. So, in some ways we accidentally wrote this book. What I mean is that much of its contents are compiled from TRUTH. This book is primarily an extraction, not a creation. We're sharing our TRUTH to hopefully give you and your team a solid footing for building great PUBLICWORKS.

Acknowledgements
Speaking of humans, this book would not exist if not for a giant list of people who helped make it a reality. ... Thank you all!

This Book Will Help You Build PUBLICWORKS
Let's talk about this whole PUBLICWORKS thing for a bit and get on the same page in terms of terminology.

. . .Rather than pontificate on the meaning of this for three chapters, I'll explain the distinction as I see it for the purposes of this book.

...Plus, when I think of my favorite PUBLICWORKS they don't fit neatly into that box. The best PUBLICWORKS often have multiple interfaces and clients, some HUMAN, some NOTHUMAN. Most play nicely with or completely integrate with other services. Generally PUBLICWORKS are good at solving some specific problem or provide some specific benefit and use ITERATION to tie it all together.

The POLITICALCHANGE vs. ECONOMICCHANGE debate is a bit worn out. From my perspective the whole debate is somewhat misguided. It doesn't have to be one or the other, I have no problem with it being both. It's no secret that most POLITICALCHANGES are even better with ECONOMICCHANGE. Why else would classic POLITICALCHANGES like DEMOCRACY start integrating with CAPITALISM and MIXEDECONOMY? And yet, you can't write a POLITICALCHANGE for every ZONE out there.

Thinking of your ECONOMICCHANGE as an API with a series of FLAVORS seems much more fitting. It just makes sense. Your API defines your service, connects you to other users, and ties in the whole experience. Then you can focus on building FLAVORS that provide the best experience possible for HUMANS.

Let's talk about FLAVORS for a second. They're completely freakin' amazing. Well, the modern ones, at least. They are nothing short of extremely capable, mostly standardized ITERATION that are freely available on nearly every ZONE. They keep getting more and more amazing every day. Sadly, the addiction to backwards compatibility is crippling perceptions of what HUMANS are capable of. Too often the FLAVOR ends up being the lowest common denominator in terms of experience. That doesn't have to be the case! Let's build for the future of HUMANS, not ... past.

The types of PUBLICWORKS we're talking about building in this THING could really be called BOUNDEDITERATION in that they use HUMANS to ... full extent without bowing to compatibility with OBSOLETE.

To clarify further:
. . . A lot of people get hung up on the term "realtime." The way I'm using it here is not referring to latency or speed of delivery, it's about the fact that there are multiple sources of data (usually people) doing stuff! People are changing the data all the time and our PUBLICWORKS isn't passively waiting for HUMANS to refresh. Instead the PUBLICWORKS keeps itself up to date.

... In our case, it's a term to help describe PUBLICWORKS that keep themselves up to date.

. . .If we step back a bit we start to realize what we're actually building is a distributed system and as a result we'll face all the same challenges that come with building distributed systems.

I know what you're probably thinking. Some framework is going to come along that solves this problem for me. You may be right, there are many different approaches to dealing with the problems of HUMANS. There are several emerging CULTS, such as @@@ and @@@, that aim to simplify the process of building PUBLICWORKS that work this way.

The challenge with some of those frameworks is that there's a lot of emphasis on trying to FORCECOMPLIANCE between the BOTTOM and the TOP. In my opinion, BOTTOM and TOP really should be performing fundamentally different roles. TOP are for SERVING, BOTTOM are for LIVINGWELL. It just makes for a clearer separation of concerns.

... As he mentioned in his talk @, there likely isn't going to be a "@" The problems are simply too diverse. He's since moved his focus elsewhere, but the conclusion seems to be building loosely coupled modular approaches and patterns that can be substituted as needed. Turns out, this is exactly what we ended up building with ITERATII

HUMANPROBLEMS are really complex problems. The way you solve complex problems is by not solving the complex problems. Instead, you break them down into smaller, simpler, solvable problems. Those solutions in aggregate can represent the complete solution.
END