My Lessons Learned on Learning

NOTE: This is my experience and very much YMMV. I’m NOT telling anybody this is how or what they need to do to be successful learning, it’s merely ideas you can borrow or steal! Enjoy!

I had just, after a couple years of intense music studies, shifted into computer science at college and learned something very important about myself. I signed up for Computer Programming 1, the most beginner of beginner classes on computer programming.

The class started and very early in the first few weeks we’d studied control structures and variables. We were in the midst of writing our first program and I’d gone into my ADHD induced dozed off state, while mind you being wide awake with eyes wide open. However as I sat there, my eyes did start to shut. In a mere moment I relaxed and fell sideways. I awoke in the process of falling, grasped the desk with my hands, as if it was anchored to the ground. However it was too late, the energy of my fall exceeded the lack of weight in the desk, and I uprooted it with a screech of the metal desk feet on the lanoleum tile floor.

BANG, the desk hit the ground and I, now laying 90 degrees of sitting upright with my desk gripped in my hands and me riding it into the floor like a pilot in a plane. Fortunately, being a long haired metal head with plenty of meh I wasn’t embarrassed so much as confused. I announced, “I’m fine!” and got up to a few smirks and smiles from classmates. One of the students spouted, “that’s Adron for ya” as she turned to face to the front of the class again. The teacher asked if I was, “ok”. I responded, with the second free lesson of the day, “I’m fine just got a little bored and distracted.”

The teacher smirked and shook her head at me. She then contineud with the class as I set my desk upright and sat back down to continue too.

The Lessons

first and foremost ADHD will thrash me into boredom and I will entirely phase out when being “taught at” vs be “informed while I learn” or “learning together”. You see, I simply don’t do classroom style learning, I teach myself and then work with people to move past stumbling blocks. It’s a wonderful way to learn.

second lesson was that, one shouldn’t spout of that they’re bored in class. It’s just not cool. Be polite, state things constructively and people will help you.

Benefits of The Teacher

However amidst all of this fracas that I caused, the teacher noticed these things that I had yet to truly learn. She notified me after class that I needed to schedule a time to meet at my earliest convenience. I did and later the next week we met.

At this meeting she, in blunt directness said, “I know you’ve very likely got ADHD but you’re doing great with the class. I also bet you don’t do well with structured teachings, which is why I’m going to give you the rest of the semester’s assignments and let you have at them.”

I was blown away, confused, and impressed at her introspection and reading of me. She added to this though, the third and most valuable lesson of this entire class. This lesson was more valuable than anything I’d learned in college or life up to this point. It was something I knew, without knowing that it was something I could put into words. She said, “if you’re like me, and I suspect you are, I’m not going to hold you to attending every class. Make sure you come in for the tests though, and try to come most of the time, but mainly just get the work done. In addition, get up every hour or so and change the place you’re working, or just walk around. It’ll prevent dozing off.”

She added one more thing, “Oh, also, don’t be the accidental asshole, no need to say you’re bored in my class. Just keep that to yourself you already have fans and friends in the class regardless of you knowing it, no need to give me shit about your boredom.”

The Lesson Trio

Through this these three lessons were reinforced, I’ll call them:

  1. Learning Together Alone – My ability to learn, fast and effectively, is dictated by my ability to hone in on specifics, put those into memory while taking in the abstractions of the ideas at hand. If any questions come up, joining forces or asking a teacher complete this process for me. No classrooms, no needing to sit and be told things that I could easily read 2-10x faster, no need to have concepts pushed at me in a specific dogmatic path.
  2. Be Constructive – Again, just like traveling from point A to point B, we’re all just trying to go somewhere, and we’re all working at this learning thing. Work together, not at odds with each other, everything is better then!
  3. Take Breaks & 3rd Place Displace – When learning, especially with ADHD, you have to break your own super power of hyper-focus as much as you have to battle that of absolute, uncontrollable, and forced distraction. If you can get one under control, you can get them both to work in your favor! Using 3rd places to your advantage, like coffee shops or parks, to do work are extremely effective. Add in a break every 45 minutes or so and you can create an amazingly productive, powerful, and efficient workflow to learn and to simply get things done!

My respect for my teacher just shot through the roof. Not only was she no bullshit, she read me like a book, but she also just pointed out what I needed – these obvious things that I would have otherwise likely missed for many more years.

I took these lessons to heart and started what would become my frequent use and displacement from coffee shops. In addition it taught me that to be truly efficient and effective, I need chunks of time but also need to break up those time chunks with something more significant than looking away from the screen. I need the option to get up and walk away, take a hike, ride a loop around a lake. Something, anything more than merely sitting there and pondering that I’m taking a break.

That brings me to my next blog entry “Magic 3rd Places”, that I’ll have posted soon. I’ll delve into much deeper detail about how I use 3rd places, what 3rd places really are and how I keep my impact to others and myself to a minimum while making use of displacing around 3rd places frequently.

A Review of the MX Ergo Advanced Wireless

FYI: No, I was not paid, nor given these freely, nor do I have any connection to Logitech at all.

A short video of the EX Ergo, the hardshell case I picked up for it, and some commentary about using it in different locations.

A few months ago I picked up a new trackball. It’s one of the multitude of pointing devices I use while working. Just to note, here’s the MX Ergo in its normal spot hanging out with my Apple Trackpad and Logitech m331 Silent Mouse.

The Pointing Devices

I picked this up to replace the older trackballs that I used from Logitech previously, the wireless and wired trackballs had lasted me a solid 5+ years at the youngest of the devices. This trackball however has a number of additional features that dramatically increase the usefulness of the device. I’ll enumerate and elaborate on a few’

  1. The scroll wheel doesn’t just scroll, but has a forward and back feature. Just push the wheel to the left or right with your finger and so goes the navigation.
  2. There’s a metal tray that it sits on, and the angle can be changed from zero to 20 degrees. This position can really change the stressors on the upper arm, which makes for easier use during the course of work.
  3. There are the normal right and left buttons, but also two buttons to the left of the left button, and two additional toggle buttons on the lower end of the left right buttons and on the left side near the ball itself. The toggle by the ball actually changes the speed, and thus increasing the accuracy of position of the cursor, it’s a strange but useful effect when manipulating images or such at a pixel level.

This device is also wireless, and has internal batteries that can be charged via the included USB cable. Standard USB connection required for the sensor for the trackball too.

A few shots of the pointing device all pretty and professional. Keep reading below the trackball gallery.

Why a Trackball

One of the issues when working remotely is that space is often constrained. When in a coffee shop, you don’t want to be the asshole who has all their laptop gear spilling over into areas beyond where you sit. Sometimes you may get lucky and the table space may be abundant, but often it is not. Using a trackpad eliminates the excessive space required for a mouse, as a trackpad just stays in the singular spot near the laptop that you set it.

You might ask, ok you have a trackball but why not just use the trackpad? Well sometimes you still can’t use the trackball, because the space is that limited, especially on a transport mode like passenger airlines. Even in first class you’ll be pretty pressed for space. On a Greyhound bus, if you feel like tempting madness, you have even less space than that and no first class to speak of! In these cases, the trackpad is all you can muster for use. But in cases where you have even a little space, the trackball can come out for use.

Why a secondary pointing device? What makes a trackball so great besides the minimal space it uses? A few things make a trackball more bad ass than most other options. For one, the movement can be more precise, with less training. One can train their thumb movement – or fingers if you want to use it that way – in a way that the arm movement used for a mouse just can’t replicate. Some may say, “oh but just use only your hand for the mouse”, well ok except that defeats the immediate ease of access for a mouse. The core notion here, is you can do this if you want to. Thus, you have reduced space use, reduced physical movement for yourself, you can increase precision, and with this particular trackball, you’ve even got macros and other programmable options for the button array that enhances the use of tools like Photoshop where that precision is a requirement for effective use!

For more reasons, more coverage of the hardshell case, check out my post on Transit Sleuth “Traveling Trackball, AKA “GSD Better!”” speaking solely to the traveling use of the trackball and the hardshell case.

All in all, a great device. Do I recommend it? Well, you’ll have to watch the video to see. 👍🏻

Coding Effort Introspection, 2nd Quarter Workshops, Code Sessions, & Twitch Streaming Schedule

I began learning Vue.js with sincerity a few months ago. But I also started several other #100DaysOfCode efforts (Database Dev Work and GraphQL Design & Dev) at the same time. This, in hindsight wasn’t the best idea. Since I was going to work on some of the #100DaysOfCode tracks outside of my regular day’s workload tackling multiple language stacks, even with the experience and familiarity I have with so many existing stacks it didn’t put me in a position to succeed.

But I digress, even in failure lessons have been learned and I’ll be beginning new with a different plan just next week. Hopefully, not only will this plan work better, but it could tangibly be of much better use for anybody that would want to learn these things too!

With that, I present, the new plan!

Starting on the week 27th I’ll start streaming on Wednesday at 5pm Pacific on Thrashing Code. On the Hasura HQ Channel I’ll be streaming on Tuesday at 9am Pacific and Thursday at 9pm Pacific, scheduling on two time points to cover more of the globe. Instead of daily hour long segments, these will likely go on for a few hours and it’ll be easier to join, ask questions, hang out, chat, and all the things that make a stream entertaining and useful. The lagniappe of this schedule will allow me to more easily cut shorter segments for those that will find those useful, but can’t really join for the longer session. It’ll be a win win for me and the audience.

Thrashing Code Guests

On the 14th of July, Russell Spitzer will be joining me to talk about tech stack, dev environment, and very likely a few things about ole’ New Orleans! Join us for that conversation and let’s dig into all the topics!

The Music of Thrashing Code

The music streams, alas, are again pushed further into the future. I’ve decided I’m going to put together a little bit more before I start streaming that, plus I’d like to get a little bit more into practice before shredding live on stream. For your sake and mine! 🤘🏻

To join in on live sessions;

Aside from the regularly scheduled things above, I’ve scheduled some workshops again as people found those useful. These workshops I’ve scheduled below. It is important to note that these are in addition to the workshops I will provide in the coming weeks and months through Hasura.

  • Getting Started with Hasura GraphQL API and Postgres (Click for tickets)
    • Short introduction to GraphQL
    • Server
    • Client
    • Architectural Overview of Hasura API Server and Tooling
    • Instant GraphQL API
    • CLI Tooling
    • Building a GraphQL Schema with the Hasura Console
    • Database Schema (vs GraphQL)
    • Tables
    • Data Types
    • Relationships
    • Overview of Migrations
    • Using Postgres Functions
    • Short identifiers
    • Default columns (functions & triggers)
  • Full Migrations, Metadata, and Seeds Workflow with Hasura(Click for tickets)
    • Migrations
    • Setup for migrations workflow
    • Versioning migrations.
    • Metadata
    • Setup metadata for workflow
    • Versioning metadata
    • Seeds
    • Setup seeds for initial data loads
    • Versioning seeds
    • Peripheral Workflow Tools & Practices
    • Docker & Local Database Environment
    • Additional Tooling
      • Visual Studio Code
      • JetBrains DataGrip
      • JetBrains Database Plugin
      • Postgres pgAdmin
      • SQL Server Enterprise Manager

Future Workshops

Quick Link to Poll for Priority: https://docs.google.com/forms/d/e/1FAIpQLSdrxPEjPqDLn8GhG1pVOvrhMXP_0LEBqiJirIOUsLkQWA1_jw/viewform?usp=sf_link

Finally, a little help from you dear readers, below I’ve added a poll of several presentations and workshops that I’d like to give in the coming months and would like to get your suggestions on prioritization – i.e. which would the most of you find useful for me to focus on first?

  • SQL Coding (Click to vote) – An introduction to SQL coding. Covering the following material:
    • Introduction to what SQL is and the history. Including, why it’s pronounced sequal, not S, Q, L, and that it does not stand for “Standard Query Language” because nerds are funny about their naming of things, and naming is hard!
    • The basic structure of SQL statements. How they’re built from object, predicate, and verb formation.
    • Putting together a database with SQL. Including creating a database, schema, table, columns, and how to alter these elements.
    • How to go about editing and dropping the elements we created.
    • A quick overview of database migrations.
    • Query writing, joins, inner and outter, and the deluge of Cartesian products.
  • Data Modeling with Relational Databases (Click to vote) – A dive into the 3rd normal form, and the normalization and denormalization of data, including nuanced tips n’ tricks to types and modeling.
    • Basic data modeling, normal forms, and the implications of building schema around normalized forms.
    • Denormalizing schema.
    • Data types and their usage around data modeling.
    • Data types and their implications within data modeling.
    • Common tips n’ tricks for using data types to build effective normalized or denormalized schema.
  • Advanced SQL Coding(Click to vote) – Going beyond the introduction material and delving into the depths of query writing, batch processing, transactions, and other advanced features of SQL.
    • Writing a basic query and growing this complexity to advanced joins, views, and query options to make data available.
    • Getting Cartesian products and ensuring we don’t.
    • Denormalizing data with SQL and some of the complexities of doing so once you have data, and especially with lots of data.
    • Writing loops in SQL and why not to do this.
    • Other SQL tips n’ tricks to awesome SQL coding!
  • GraphQL Servers (Click to vote) – Need a custom GraphQL server? Not sure where to start? In this workshop I’ll provide an introduction to writing GraphQL Servers. Somewhat a language agnostic workshop, but I will pick one to implement a server in for reference in the workshop. Ideally we’ll pick one before the workshop and I’ll use it based on what the students in the workshop would prefer.
    • Introduction to GraphQL Servers and what they do and how they work.
    • Elements of a GraphQL Server
    • Schema
    • Data Set
    • Resolvers
    • Query Operations
    • GraphQL Types
    • Aliases and Fragments
    • Variables
    • Query Nested Objects
    • Directives
  • GraphQL Clients (Click to vote) – This workshop assumes you’ve got your GraphQL Server all setup and ready for use. Now we just need to ensure our clients are getting, and using the data from the server effectively.
    • Client options for the various languages stacks; JavaScript, C#, Java, Go, and possibly other languages.
    • Implementation of queries and mutations in;
    • JavaScript via client and Node.js Server calls (server acting as client).
    • C# and/or Java calls as clients.
    • Go calls as systems client.
    • How to deal with JSON results with JavaScript, C#, Java, and Go.
    • JavaScript with JavaScript Object Notation.
    • C#/Java options for managing JSON.
    • Go options for managing JSON.

Getting COPY For Bulk CSV Working on a Container Running PostgreSQL

(Video is available at the end of this post, be sure to check it out for further details)

First off, check out this post if you’re curious how I put together the csv file. There is a ton of data out there that you can just download that is in csv format, but I wanted to have data that was specific to a DDL (Data Definition Langauge) I wrote. Once I had a file, I went through the following steps to make it easily repeated through automation.

With that file make sure, at least for this example, that the first row of data has the column names as the commas seperated values. It should look something like this (per my example mentioned above), and obviously have far more data than the example below.

id,country,ip,created_at,updated_at,project_id
4cf25606-5f3e-4575-86ea-c585513fcc39,Solomon Islands,169.137.96.151,2020-12-25T05:04:26.124Z,2020-12-30T11:04:26.124Z,d6ef3dfd-9596-4391-b0ef-3d7a8a1a6d10
cbeaf6ab-23cc-43c5-a740-7191f59d8cc5,Solomon Islands,106.92.223.22,2020-12-25T05:04:26.124Z,2020-12-30T11:04:26.124Z,d6ef3dfd-9596-4391-b0ef-3d7a8a1a6d10
17a7ec0b-2758-4721-b104-f368c8109b6a,Solomon Islands,248.8.206.229,2020-12-25T05:04:26.124Z,2020-12-30T11:04:26.124Z,d6ef3dfd-9596-4391-b0ef-3d7a8a1a6d10

Now my next steps was to get this file copied to the server where the database is running. To check the containers I have running I call a quick docker ps to get a list.

The container list of running containers.

In this list, the PostgreSQL server is the container named pgdb. To copy the file to that server, the following command will get the job done.

docker cp ./name_of_file.csv pgdb:/name_of_file.csv

If you’d like the destination name of the file to be different, that is possible in this command too. I like to keep them the same to prevent confusion. For example, if I log into the server and have a bunch of terminals open, seeing the file named on things one place and another in the other place, that’ll throw a wrench into things.

With the file copied, I can now run the PostgreSQL command to bulk copy the data into a table. The command to get that done looks like this.

COPY the_table_where_the_data_will_go FROM '/name_of_file.csv' CSV HEADER;

That’s it! Well ok not really, this is one of the simpliest use cases. Such as, if any columns don’t map one to one with the column names of the csv file to the table column names, this command won’t work as is. Check out the COPY documentation to get the details on how to use the command if you have various things you need to tweak for your own work. However, for this basic premise and for what I want to talk about next, that’s it! 😁

To get into more details about how I automated this process, check out the video.

A Story of an Ivory Tower Architect Clusterfuck

Astronaut Architect or Ivory Tower Architect – Both of these are generally terms of dirision toward software architects who have become disconnected from anything related to actual implementation, coding, or related knowledge and work that has to do with the work of building software applications and services.

Astronaut Architecturalism or Ivory Tower Architecturalism – Topics that an architect might bring up which could be a sign they have reached the Ivory Tower or Astronaut level of architecture work with software. This ism is something to be very concerned about, as sometimes these individuals can completely derail and wreck a project with lofty – yet extremely disconnected ideas – about how or in what way the software should be built for a project.

Chief Emotive Product Technology Architect

Circa 2004 – In the city of Portland, Oregon.

The team, a reasonably sized startup team, of ~12 people sat around the table. It was a oval shaped table, specifically in this conference room so that all members could have involvement while seated at the table, in a conference room called “King Arthur’s Round Table”. Oh, the “LOLz”. The 12 individuals had been working on a project that was a B-round funded venture that had to do with musical things. These 12 individuals had so far, self-organized and been working at a reasonable clip, to get this software built and realize the ideas behind the venture.

The 12 had been gathered here by their manager so that a new member of the team could be introduced. Nobody knew who this person was or what the role of this person would be, except of course the hiring manager. Because I suppose, that was how things were going to be done in this year of 2004 with this startup with this manager. Yes, all sorts of indicators were already being fired off for the experienced of the 12. As these indicators fired off in their mind, concerns were growing, but the experienced had kept their mouths shut so far and offered the manage the benefit of the doubt.

The manager, who I’ll call Thomasen stood before everyone, in conflict with the ideals of Arthur’s Round Table. Thomasen mentioned the ideals of Arthur’s Round Table, which seemed ironic since he stood there before – removed from equal voice by the mere act of standing and spoke to everyone. But also it seemed fitting, for he then announced that he had hired a new member for the team. This unilateral decision of Thomasen’s seemed as if done in spite of the ideals of the Round Table, in spite of his just stating the ideals of the Round Table. What kind of fresh hell was being birthed at this moment? Well, that’s were things get lit, if not outright explosive!

Ericson, one of the experienced developer’s asked, “Ok, you just made a unilateral decision to hire someone, but what even is this person’s role? What are they gonna do here?” Thomasen replied, “I’ve hired Jacobson Tirelorn to join us as the Chief Emotive Product Technology Architect!” To which, the metal head of the team whipped to attention in his seat and inquired, a bit forcefully as a metal head might be imagined to do, “What the Holy Hell fuck is a Chief Emotive Product Technology Architect?”

Thomasen replied, “Kirk, jeez man you don’t have to be so aggresive and vulgar, could you tone it back about 10 notches?” Kirk, not one to take bullshit at even volume level 1, let alone at 11, responded kindly with a simple statement, “Nope.” Thomasen breathed heavily, the sigh clearly evident to all in the room. The newer folks of the 12 watched this with apprehension, while those that were familiar with Kirk’s lack of accepting bullshit, smirked as he laid out the guantlet for Thomasen. Thomasen responded finally after this long sigh, “Ok Kirk.”

Thomasen continued, “I’ve hired Jacobson Tirelorn in this role to help use build our product and really get connected on an emotional level to our users. Kirk, again sniped in, “We don’t have users yet we’re a startup in stealth mode.” Thomasen growing frustrated, “I know but we will.” Kirk, “Sure. But what exactly is the emotional level of our users?” Grunting almost, “I’m getting to that point Kirk.”

Thomasen elaborated, “Jacobson, the architect will also help us significantly figure out what technology we’ll use for the product and how all the parts should fit appropriately to make a highly scalable solution for our users!”

Lasinia raised her hand, “Can I ask a question?” to which Thomasen responded calmly, “Sure Lasinia, what’s your question?” Lasinia started off, “Per what you said, I decided to raise my hand since I’m confused about the Round Table ideals, if we all have an equal seat why are you standing and why do I have to raise my hand to speak?” Another of the 12 responded, “you don’t have to raise your hand…” “yeah but I felt like it because we’re not really following the ideals very well if Thomasen is standing up, Thomasen, could you sit down and continue telling us about this architect you hired?”

Thomasen pulled up a chair and sat down. Muttering somewhat under his breath, but still clear to the 12, “God dammit everybody.” He sat and continued finally.

Eventually he ended. The era of theh Chief Emotive Product Technology Architect was upon the team, regardless of what that meant!

The Chief Emotive Product Technology Architect Era Begins

Two weeks after the first Round Table, Jaconson arrived and called a meeting for Wednesday. It being Monday everybody easily accepted the meeting for 8am Wednesday. On Tuesday morning Jacobson sent out a document detailing all sorts of great and lofty goals for his architect role. He was, after all exuberently ready to get things started! Maximum emotional user support and all!

Around mid-day Tuesday, after the document with the details had arrived that morning Jacobson sent out another calendar invite for 9am Wednesday. Again, everybody went along with this and now had an 8am and 9am meeting scheduled for Wednesday! However, the foreshadowing got amped up another level when Jacobson is his zest and zeal sent out another meeting for 1pm that Wednesday. This meeting invite, however, was sent out at 4:51pm on Tuesday, which would have placed the meetings at 8am, 9am, and 1pm. The scheduling, and titles, went something like this.

8am – Software Release Schedule
9am – Emotional User Stories
1pm – Design Studies

This was going to be one helluva kick off of the Chief Emotive Product Technology Architect Era!

The day rolled around. Having sent out that 1pm invite at 4:51pm multiple people had not received the invite in time to know about the meeting before the 8am meeting kicked off. Thus, this is when the horror of the era truly began.

8am everybody stood at the door to the conference room, again King Arthur’s Round Table conference room. The time ticked past 8am. This seemed normal, it was after all Portland and rarely are people precisely on time on the west coast. 8:03am ticked by. Still, none of the 12 were concerned yet as Thomasen arrived to open the door. Again, this whole irony here, being the door to the Round Table conference room was locked, as if someone was going to sneak in and steal the massive multi-hundred pound table?

Thomasen and the 12 all sat down at the table. Being 2004, Thomasen was the only one with a laptop, another important piece of context here. In 2004 most people still programmed at desktop machines, thus, barely any of the 12 knew of the 1pm meeting, but were still ready to get things started and give this thing a shot!

8:31am arrived and Jacobson walks in as if no tardy one moment. He then pulls out a chair and sits down at the table and announces, “Hello everybody, it’s great to be here I’m Jacobson Tirelorn and I’m going to help you get this software solution, your processes, and your emotional well being figured out!” Kirk, yes Kirk again, spearheads the next immediate assertion, “Confirming, you’re going to help with the software solution architecture, the processes for the project, and our emotional well being? Why would I want you to help me with my emotional well being? Is there an assumption my emotional well being is fucked up?”

Now I need to paint some context here. Jacobson had entered the room casually, as if not late, but also wearing the garb of a 1970s era hippy. Multicolored attire and jeans, which wasn’t to crazy for a startup in Portland, but was still slightly dated and odd for this era. To add to this off-date situation, Jacobson looked like he was approximately 18 or so years old.

Thomasen chimed in, “Kirk, we’ll talk about your emotional well being later, let’s go ahead and let Jacobson get into the architecture and planning first.” Kirk “alright.” shrugs.

Jacobson starts in on some wording, “Alright, what we’re building is going to need to scale, massively, at a moments notice and currently we’ve only got the capacity for about 20% of this capability. So we need to really amp up our systems and our architecture to handle 150% of our expected capacity! With that in mind I’ve drawn this architecture diagram to help us get there.”

He then commences to put this on display, after messing with a projetor for approximately 5 minutes. What he then shows looks like a soup bowl was spilled out onto paper, which bright colors and odd shapes representing the Sun Servers, which were drawn not with the icons of the era that represented a Sun Server but with actual suns showing bright yellow. The network connections and backplane were shown with fuzzy ropes and other tangled bushes. It almost looked more like a wildlife sketch about the magic of the birds and bees than anything to do with software.

Jacobson then made a statement that immediately shaped the project, “What I’ve done here is use a little artistic license to draw up the server and network diagram that will get us to the needed scale!”

All of the 12, in their minds, and with their coursing eyes looking amongst each other thought in horror and disbelief. The all imagined that an oil train had just derailed and fell from a cliff into the ocean. As Jacobson continued the idea spread and so did the oil spill idea, as if it were lit on fire to burn uncontrollably.

Jacobson continued. He talked for the raminder of the meeting and then stated, “everybody take a bio break now and grab a snack for the next meeting, we’ll all meet back here at 9:05am to get started on the emotional user studies.”

At 9:05 everyone except Jacobson and Kirk entered the room and sat down. Nobody spoke, but just sat and waited patiently, some snacking on food and others just pondering what was going on. At 9:11 Jacobson walks back in and shows another chart that resembled Maslav’s Heirarchy. He then asks, “Where is Kirk?”

Kirk walks back in at 9:12, just a mere minute later and Jacobson says, “Good you’re here, a little late but we can get started now.” Kirk states, “you walked back in here a minute ago, it’s 9:12 now. You were late, I’m just following your lead.” Jacobson seems to not even acknowledge that Kirk has spoken and being a spiel about emotional well being.

Just a few minutes into this Sarah, one of the 12, new to the team asks, “What are the key aspects of everybody’s well being should we primarily be focused on?” “We should be focused 100% on the zen of people’s well being.”

Kirk stands up. Walks toward the door and leaves. Thomasen responds, “go ahead and continue Jacobson I’ll see what the problem is.” Jacobson continues.

Meanwhile Thomasen and Kirk have a chat, Kirk states simply that this guy is bullshit and you can keep me and I’m just going to work on the project or you can toss him, but I’m not going to work with this guy while he spouts this nonsense. Kirk having been key so far the lead of the development teams and practically a founder, leaves Thomasen to agree to the terms. Kirk informs him he’ll give Jacobson a chance but isn’t going to listen to the emotional zen nonsense, so he’ll be in other meetings, and Thomasen seems relieved, and life continues for the project.

Thomasen rejoins the meeting, and the meeting runs on and on and on and on. At 12:07 Jacobson says, “everybody take lunch now and we’ll get back to things later! thanks all!” To which everybody, releived, heads off to lunch. But do note, not a single person of the 12, except for Kirk, has been back to their desks to work or read emails on their desktops. Not a soul, except Kirk, knows now that there is a 1pm meeting. Not even Thomasen.

1pm rolls around and Kirk walks into the conference room ready for design details. Jacobson enters and immediately states, “well I guess since you’re the lead nobody else really needs to join us.” But Kirk knowing the anti-pattern in that states, “Well, others should join us as everybody needs to know the design of the system that is going to be working on the design of the system.” “Well, you Kirk can tell them later right?” Kirk smiles wryly and laughing says, “Alright, this is turning into a train wreck already so yeah, let’s go with that idea.”

Jacobson informs Kirk of his ideas.

Kirk finishs the 1pm meeting with the conclusion that Jacobson is an Ivory Tower Architect of no use to the team that needs to implement the product.

Three months pass. A status meeting is called by the CEO of the company. It starts off plainly.

“So how are things going team? I’d like to get a preview look at the product before our coming release in two weeks.”

Kirk looks up and asks, “In two weeks?”

Jacobson responds, “Yeah, we’re releasing in two weeks.”

Kirk and Sarah both look toward each other and simultaneously ask, “We’re releasing what exactly?”

Jacobson starts to respond and says, “It’ll be version one of the prod…”

Thomasen cuts in, “Wait a second, just to clarify we’re releasing a beta of the version 1 of the product.”

Sarah, “So like, an alpha product?”

Jacobson, “You could say that, but it’ll be more like a beta, using the design patterns we’ve implemented and architecture I’ve designed.”

Larry, one of the 12, softspoke and rarely speaks unless specifically asked a question, “What architecture and design patterns?”

Kirk says, “The ones Jacobson dreamed up, but don’t worry, it’s those that I’ve shown you but we don’t really call them design pattersn. We’ve just been calling it our architecture.”

Larry, almost assured “Oh, that, ok. But, per Sarah’s question, what are we releasing exactly?”

Jacobson says, “The v1 product.”

Thomasen corrects, “The beta v1 product.”

The CEO asks, “What about the alpha product?”

Thomasen “There is no alpha product.”

Jacobson emotes “Well, we could just rename this the alpha v1 product.”

CEO stands, causing consternation among everybody, “What do you mean rename, we don’t have an alpha product? How can we not have an alpha product and we’re about to release a beta product? Why do you keep skiping the beta part and saying v1 and Thomasen keeps interjecting beta? Who the fuck is in charge of this?”

“I am, and Jacobson is building the architecture design.”

“No he’s not” interupts Kirk, “I’m building the design based on Jacobson’s architecture.”

As you can imagine, none of this is getting resolved quickly, so let’s fast forward to the results of this CEO scheduled meeting.

Post Trash Fire Meeting SITREP

The SITREP, or situational report, went something like this. The meeting went on for another twenty plus minutes of the CEO, Jacobson, and Thomasen being confused about alpha, beta, and v1 variations and Kirk eventually sat back and just let it happen unabated. Sarah got up about 15 minutes into the meeting and nobody noticed she left. In addition to leaving the meeting though she went to her desk, got her personal things and left never to return again.

The others among the 12 listened and eventually faded out and started ignoring the clusterfuck that unfolded before them that day. Two others besides Sarah left within the next three days. A week after that meeting, Kirk decided he was done too and resigned. Jacobson, being the root of many of these problems was fired by Thomasen, which then the CEO in a fit of rage, merely 2 weeks after this meeting as the startup fell apart, fired Thomasen.

4 Weeks after that meeting the CEO was then fired, even though a founder, and the board having all the power to do this started the process of rehiring everybody to fill the roles of those that had left. First they managed to get Kirk to come in for a conversation about what exactly went wrong.

Board inquired “So Kirk, thanks for coming to speak with us. Could you tell us about what exactly happened? We’re not really sure ourselves.”

Kirk happily, ya know happily for a metal head, smiled and simple said, “Not really, I know, but it’s not worth going into.” and then turned just a bit and opened up a laptop he’d bought. “However, here’s some design and ideas about what should be built to acheive what you want and how much it’ll cost to have me come in and get it done.” The board started looking at the architecture and then asked, “Could you elaborate on what all this architecture shows us?”

Kirk went on to detail, in depth the technical challenges and what the design would require to meet or exceed the needs of the prospective userbase. Then, the board flipped the page after they had felt they understood enough. On this next page of details Kirk had layed out a SOW, or Statement of Work, to detail what he’d cost and what he would do to make this happen. The board was agast at Kirk’s hefty 2004 hourly price tag of $100 per hour. They stated they would have to think about it.

A week later they decided, after talking to Jacobson, to hire Jacobson at $80 bucks an hour to lead the effort around the architecture that Kirk had shown them. At least, to the best of their memory.

The project kicked back off again, now many weeks behind. At this point you might know what happened next, Jacobson cratered. He left a blast radius of unhired roles, unfinished design that didn’t make sense, and a massively unfinished project. This took about 4 months before the board wised up to their poor hiring decision, and having hired this astronaut architect stuck in his lofty ivory tower, they then opted to fold and reposition the company, eating the entirity of the losses.

TLDR Summary

2004 was a whopper of a year, considering the economy hadn’t even improved much after the 2000 apacolyptic tech crash! It was a time when many startups had survived with just enough of their hubris and naivety intact that they were trying some pretty crazy things trying to get products and services delivered. In spite of that, many continued failing.

At this point I want to add an important caveat, that the names are changed but this is the recollection of events from multiple people involved in this particular startup. This wildly happened more than a few times during this period when many startups went under. However, many others started to rise from the ashes during this time too.

Moral of the story, beware the astronaut or ivory tower architects!