2020-04-06 This repo is no longer being updated, I began writing this to master SpaceVim workflows; I now slay in SpaceVim, which has become my IDE of choice. My personal thoughts, arguments, and research related to whatever this is becoming will continhe via Juypter Notebook.
Note: I stumbled upon the book, 'Systems Engineering in the Fourth Industrial Revolution: BigData, Novel Technologies, and Modern Systems Engineering' last week; and it has been one hell of a find; it's a roadmap for the introduction of evidence-based practice(EBP) as a core component of systems and software engineering practices for the paradigm shift currently underway in this field/industry. Furthermore, it argues that software development/engineering practices will be required to adopt IT governance ways of doing things or collapse from architectural technical debt; I will be updating this further once I have finished the book.
Aligning my background with the world of Software Engineering has been the single greatest personal challenge I faced to date...
The following words defined the spirit of a passion project called Nerdy Pug Studios that closed overnight in 2018 due to platform-dependence on Etsy...
Our evolving identity is a fusion of multiple stereotypical industry traits, combined with a strong respect and adherence to the empirical and evidence-based practice approach methodologies. We're science geeks, and our creations, particularly our harnesses, are the result of extensive research, development, and prototyping.
You can checkout the Internet Archive or see a summary of screen below from July 2018...
Nerdy Pug Studios
The question I never expected...
A few days after my code school graduation, I reached out to Jeff Meyerson, the creator and host of The Software Engineering Daily(SEDaily) Podcast via the shows Slack Channel.
I have been a devoted listener of this show for three years, in the beginning I understood maybe 20% of what they talked about, but I loved it anyway.
I just wanted to thank him for the work on does on his podcast, and that I just finished after years of being I could never be a software engineer.
I love the hard questions he asks on his show, and after congratulating me he asked me a something I wasn't expecting...
He said...
Now that you can program, what are you going to contribute to the world of software, what impact are you going to have?
I never was expecting to be asked such a deep question, and I had no answer, so after a few minutes of silence I said, 'Let me get back to you tomorrow.'
The next day, I still had no answer, so I messaged him and said, " I will have to get back to you on this,'to which which he replied,
Please do I want to know.
It was his question that sent me on an eight month long journey through empirical and scientific paper research to locate an answer...
In June of last year, when he asked me this, I knew that I wanted to be a future guest on his show; my goal was to do it within 3 years, so I have about 2 years and 4 months left.
I still have not replied to him to let him, because I need this repo to outline the next 18 - 24 months as a roadmap to the answer I will give him.
This is a work in progress...
In the months since my code school graduation, the 00:00:00 timestamps that litter my DigitalCrafts GitHub era private repos have enabled me to use the recorded video lectures for a post-mortem analysis of my student developer experience at DigitalCrafts; and the insights I have gained from this process have been life-altering.
Imposter Syndrome
A few years ago, I started a Masters in Information Systems(IS) but stopped taking classes after completing 1/2 of my program because I was plateaued in my IT career due to an ability to code/program.
I was always been embarrassed by the BA in General Studies on my resume, so much so that I let the self-doubt of imposter syndrome consume me in my post-DigitalCrafts software industry job search.
My technical/IT background landed me interviews that most code school grads would have been passed over for by HR/IT Recruiters, and I witnessed firsthand the ‘stigma’ of the ‘coding bootcamp graduate’ stereotype that so many Senior SEs hold.
This 'stigma' is widespread due to the rise of 'nerd-masculinity' in the field of computer science that occurred in the 1970s to early 1980s as the sector transitioned from a female-dominated one to a male-dominated one, and it remains widespread through senior-level engineering positions in all sectors.
NETWORKS OF EXCLUSION IN A GENDERED ORGANIZATION IN THE HIGH-TECH INDUSTRY
I found the following passage from this research paper particularly insightful on the topic...
The masculinization of software and computing occurred later in the 20th century, as again men actively worked to professionalize the field in line with other scientific disciplines, establishing structural and cultural boundaries in ways that excluded women from the field (Misa 2010). Newly-implemented aptitude tests and personality profiling in hiring processes, for example, privileged masculine characteristics. Increasingly specialized job titles and hierarchies distanced high-skilled labor from work seen as low status and routine, offering increased social status, greater autonomy, better pay, and improved opportunities for advancement for men (Ensmenger 2010). As men solidified their hold over computing and engineering, computer culture became associated with “nerds” – young, white, educated men who “tinker” with technology.
Pages 27 - 28
One
I was a nurse, I graduated from Gordon State College in December 2012 with an Associate of Science in Nursing and immediately passed my NCLEX for my RN license; which I let expire years ago after joining the ranks of Apple corporate.
I worked professionally as a nurse for a month before quitting, the emotional toll of a career surrounded by illness and death and losing patients every other day was something I could not do.
The science of modern day nursing education is housed in a school of scientific inquiry and thought known as evidence-based practice(EBP); which requires, at its core, strict and unwavering adherence to the scientific method in the clinical decision making process for the gathering, collection, and analysis of nursing process interventions.
The human body is viewed as a collection of interconnected systems that, in the absence of homeostatic equilibrium, results from the breakdown of systems over time…
Blood lab values, toxicology reports, vital signs, urine labs, etc, serve the purpose of providing quantitative data that modern-day nurses interpret based on the presenting signs and symptoms of a patient to determine the best steps to take with the end goal of reestablishing a patients natural homeostatic state.
Two
I wanted to go to GA Tech to study computer science, but I am a discalculic; I barely passed College Algebra with a 70. I was essentially told to pick something 'more realistic' that didn't involve the physics and calculus classes required to enter GT as a transfer student.
What I didn't know at the time, was that my dyscalculia is limited to handwritten numbers and equations on a board, e.g. in the classroom, it doesn't carry over to printed text, numbers, and equations.
The beauty of code is that doesn't carry over into the domain of vim or IDEs either.
I never struggled with mathematics, I struggled with reading handwritten non-sense on a board during lectures...
Three
I entered the world of startups as the ‘Apple’ IT guy at a startup that is now shuttered in the summer of 2017 out of a co-working space I will not disclose the name of…
I won’t go into any granular details, but this place broke me; it was, by far, the most vicious and toxic environment I have ever been in.
I was so committed to making it work and to be viewed as a ‘team player,’ that I allowed myself to be an emotional punching bag for Senior SEs and Project Managers that belittled me to the point of tears some evenings.
Since I had no dedicated space, I came in during the evening hours to set up and ship systems, and it was during these hours that I was subject to this harassment; it was equivalent to that one incident I saw at Apple…
I became so afraid, I lived on eggshells and ‘Don’t shoot I’m not a messenger’ became a phrase I would say if I walked by someone I wasn’t sure of…
I was in this role for three months, and I have never spoken about it or mentioned it on my resume/LinkedIn because it was an experience I simply wanted to ignore and forget…
Is known as Empirical Software Engineering...
Technology, distributed computer systems, coding workflows, networks, etc, are nothing more than interconnected systems that breakdown over time just like the human body, with performance and monitoring metrics/KPIs as the equivalent of toxicology screenings and blood lab values in the operational decisions making process of corrective systems ops interventions.
Evidence-based practice approach methodologies in the realm of software engineering and design are relatively new concepts, until recently, EBP empiricism simply did not exist in this field.
I now know that it was this lack of EBP at the heart of my struggles to grasp something as simple as Test Driven Development(TDD); even though I had long demonstrated a technical prowess for the single-direction logic of organizational Domain-Driven Design(DDD) on teams in where the TDD subset of Behavioral Driven Design(BDD) was the norm.
After months of objective reflection and analysis, I finally located EBP in this field, where is more commonly referred to as Empirical Software Engineering(ESE), but, for the sake of simplicity and habit, I call it Evidence-based Software Design(EBSD).
An Evolving Perspective...
Four years ago, I wrote the following words in my last undergraduate research paper...
How Gorbachev's Reforms Synergized the Intentions of the Reagan Doctrine
To highlight the nature of the inefficiencies plaguing the Soviet Union’s industrial capabilities, a review of the technological challenges faced by Gorbachev when he assumed the Office of the General Secretary provides sufficient illustration(Gibbs, 11-14). In 1977, the last year of reliable data, there were an estimated 20,000 computers in the entire Soviet Union, compared to 325,000 in the United States alone(Bailer, 77). It is estimated that by the mid-1980s, there were 25 computers in the United States for every 1 in the Soviet Union, a ratio of 25/1(Bailer, 77). With a twenty year headstart on research in the newly emerged field of computer science, the West leveraged the power of the microprocessor to automate tasks, calculate vast quantities of data in ever shorter periods of time, and instantly access this information on distributed systems thousands of miles apart through the first computer networks.
The United States had unintentionally exploited the artificial existence of Moore’s Law, which dictates, “The capabilities of computers will double every 18 to 24 months(Brock, 34).” Our nation developed the first truly computerized military systems, one such codenamed “ARPANENT(Salus, VIII).” The US even had the audacity to publicly announce what is now popularly referred to as “Project Star Wars(Cort, 77-78),” an idea born from the West’s technological capabilities to place low-earth-orbit satellites in space capable of deflecting Western bound ICBMs(Cort, 78-79). The Soviet Union was in no place to even attempt such a feat, as the rampant technological inadequacies of the USSR culminated in the global embarrassment to the capabilities of the Soviet sciences during the failure of the nuclear power station at Chernobyl in 1986.
If there ever was a wakeup call to Soviet leadership, this was it.
Arguments for Empirical Software Engineering Adoption
I argue that monolithic ITILv3 driven cultures are the most vulnerable, due to the divisional silos that result from unintentional adherence to industry SOPs that have become relics and artifacts of the past with the rise of AGILE and LEAN ways of doing things in ITILv4.
Empirical Software Engineering: From Discipline to Interdiscipline
The following excerpt is the smoking gun I needed to confirm a suspicion, a feeling, a spidey-sense if you will, that the 'high-touch' software discipline of the educational learning model used throughout the 'coding bootcamp' industry has not yet been exposed to EBP in the classroom...
Although recent developments have improved our empirical understanding of software engineering practices and processes, the current state of evidence is still weak when compared to other more mature fields. A large extent of our everyday practice in software engineering is still governed more by conventional wisdom than it is governed by empirical evidence. This is especially true for the social, cultural, and political aspects of software engineering, such as early stages of development, rendering the inference of robust theories inherently problematic.
Even though we can observe an increase of empirical studies in the various fields of software engineering research, many studies still do provide either circumstantial evidence by focusing on isolated contexts without taking into account the relation to existing evidence or – worse – they neglect the context completely. The effects are portrayed by Jacobson’s observation in the context of the SEMAT initiative [35]: software engineering is gravely hampered by
1. the prevalence of fads more typical of fashion industry than of an engineering discipline;
2. the lack of a sound, widely accepted theoretical basis;
3. the huge number of methods and method variants, with differences little understood and artificially magnified;
4. the lack of credible experimental evaluation and validation; and finally
5. the split between industry practice and academic research.
[]The consequence of the current situation are best described by Wohlin et al. saying that
“
there exists no generally accepted theory in software engineering ... Some laws, hypotheses and conjectures exist, but yet no generally accepted theory
”
As a matter of fact, a large extent of the theories (or theory patterns) we have for software engineering are still transferred from theories in other disciplines (e.g. organisational psychology), sometimes by adopting them, but mostly by transferring them verbatim [37].
Software engineering itself however is often still governed by folklore turned into facts [38]. Similarly as in other fields before, many theories specific to software engineering emerged from the early times of the discipline where empiricism had no significance at all and where claims by authorities where often treated as facts. One prominent example for such a “fact” is grounded in the wellknown essay by Edsger Dijkstra Go To Statement Considered Harmful [39] from 1968, largely based on reasoning by argument and triggering a public exchange between different scholars via published notes (all considering the previous note as “harmful” itself). Although this exchange fostered an important and fruitful debate in the community at that time, it still remained largely a public exchange between scholars based on reasoning by argument. This did not change until 2015, nearly 50 years lager, when Nagappan et al. [40] published the results of their largescale study analysing C code from GitHub repositories and suggesting that the use of goto statements in practice does not appear to be harmful.
Additionally, this applies to countless enterprise technology-first environments, teams, and entire organizations.
ITILv3 is Legacy
ITILv3 is so obsessed with process improvement in the form of written proposals, that metrics and KPIs of any type are never implemented, so the decision-makers in such orgs remain in the dark to their actual state of tech.
The adoption of evidence-based practice approach methodologies as a key component of organizational technology governance strategies acts as a safeguard against 'tradition' and the folklore behind institutionalized SOPs that exist in the form of 'we have always done it this way.'
I do not have actual numbers or stats, but, past experience in ITILv3 IT and Kanban/DevOps SE environments has provided me with the insight to know that the 'eye-opening' reality for most orgs doesn't occur until an outsider with no understanding of current processes is brought in.
EBSD adoption goes far beyond the capabilities of Splunk, Nagios, or monitoring tools of any type, because it is something that does not exist as an off the shelf tool; it's a mindset, a perspective, a way of looking at things and searching for scientific, peer-reviewed papers and case studies to assess and test the situation.
EBSD enables an org to exist in a constant state of evolution in response to new and emerging discoveries that drive innovation from the bottom-up, not the top-down.
EBSD is both an art and a science sprinkled with a liberal arts style of critical thinking and analysis that allows an org to exist in a fluidic state of continous enhancement.
Killing the 'Coding Bootcamp Graduate' Stigma
"Coding bootcamp graduates are NOT engineers..." is what I was told by Senior Software Engineers, but, what I now realize is that this field lacks credible theory and is based largely on 'tradition,' in the absence of inquiry into the multidimensional state of this field through the analysis of the scientific method and the collective advancement towards credible theories, the entire basis for their arguments exists as a house of cards on a straw foundation that is just one huff, and buff, away from being blown into oblivion...
I argue that it is the diversity of the interdisciplinary educational backgrounds of code school grads that empowers us with the knowledge to view the 'state of things' in this field from an entirely outside perspective that will enable, for the first time, concrete theories to be established in this field; it is this advantage that we have over the classically trained Ivy League-educated software engineers of the past.
Their argument is based on 'tradition,' folklore, and conjecture that's the equivalent of the pseudosciences, and our interdisciplinary backgrounds threaten to expose that reality...
The term software engineering was coined in 1968, at the NATO Software Engineering Conference by the conference chairman 'Bauer' he stated,
What we need is software engineering.
This was the world of a 1960s era 'Mad Men' episode, it portrays the 'boys club' culture at its peak in America, and it is this culture of exclusion to women and minorities of color that serve as the founding fathers of 'software engineering' as a field of study.
It was this moment in history when the rise of 'nerd masculinity' began to take hold on the field and establish the barriers to diversity and inclusion that still exist today...
The greatest threat to the status quo of the classically trained Ivy-league educated software engineers of the past is the 'God in Gaps' reveal to their existence that is well underway at this moment in time and evident through the continued call to arms to deliver on overdue promises for diversity and inclusion in the upper ranks of every sector.
I argue, that, with the arrival of the mainstreaming of the coding bootcamp phenomena underway today, that the interdisciplinary professional and educational background of student developers brings with it the risk of new perspectives and frameworks of scientific inquiry from fields with robust theories that can be applied to the state of software engineering practices, norms, and beliefs.
Code schools are the gateway for a pool of technical talent with the expertise and a fresh perspective that threaten the state of ‘tradition’ as outsiders turned jury.
As a founding member of Out In Tech ATL, I am obligated to take this argument into the halls of academia to fight fire with fire.
We have been stigmatized as being a 'bootleg' caste of wannabe technophiles by the Ivy League-educated software engineers of yesteryear who have failed for fifty years to establish theory that can be peer-review duplicated, it is the absence of doctrine based on the principles of the scientific method that invalidates any claim they have to being 'scientists.'
Extraordinary claims require extraordinary evidence.
- Carl Sagan
As a scientist, I have to ask...
Where is the evidence that code school graduates are NOT engineers?
Show me the evidence.
Expanding
I have come to the conclusion that the term 'Evidence-based Software Design' decribes the traditional process of software development on a team with a least one developer as a 'practitioner' of Empirical Software Engineering.
EBP, in all of its many forms, should be considered a highly structured way of viewing the world of software engineering through frameworks of scientific inquiry from fields with well established theories.
There is a lot of expanding I need to do on this, but, the end goal here is to drive EBSD an interdisciplinary.
Grad School
Without a doubt, I will be entering a graduate program in the next 24 - 36months to pursue an advanced degree with a focus on some aspect of technology...
However, at this time, it is far to early to decide what that degree will be because I don't have a purpose or mission in this industry.
The purpose of an advanced degree is strategic in nature, and should only be started by someone with an established presence in a specific field or industry; grad school is a highly calculated decision that requires extensive research.
The tactical advantage of a highly vetted graduate program is the emergence of deep analytical awareness for the conceptual frameworks at the heart of an industry or field.
At this time, I have no mentors or leaders in the tech industry or IT field that I lookup to for guidance and professional career development; my status and influence at Apple was strictly limited to my org in Austin, at this time, I am a nobody.
Apple Leadership
Tara Bunch, the SVP of my former org at Apple serves as a testament to the power of strong leadership, and, to this day, the message of her 2013 'One Apple' vision of a unified global company culture still inspires me.
Apple was so much more than just a 'job' to me, it was a way of life. Apple, as a company, became a critical part of my identity. To this stay, I still say 'we' when referring to my time at the company.
Tim Cook, Apple's current CEO, who leads an army of 100,000+ strong, replied within minutes of sending him an email about my roommate, who was a part-time Apple Store employee, having to take on a second part-time job to cover the upfront cost of tuition for the same college class that our third roommate, a corporate part-time Apple employee, had secured a delayed payment agreement for due the tuition assistance benefit that Apple corporate employees working 20+ hours week are elligible for...
The question I asked was simple, "Are we really 'One Apple'?"
The impact of this chain reaction resulted in the full expansion of company benefits that all PT corporate employees working 20 or more hours a week were are eligible for being extended to all PT retail store employees working the same number of hours in late 2014; I have no idea what went on behind closed doors in Cuptertino after this, I obviously had no part anything beyond speaking up for something I thought Apple Leadership should know...
I may have left Apple, but the company remains a core part of my identity to this day, and likely will until the day I die.
Note: I need to add that this was a group effort, multiple individuals across multiple orgs reached out to Apple leadership in a coordinated effort all at once.
The Absence of Leadership
April 2020 GRE
I knew years ago that I wanted to pursue an advanced graduate degree, I even started a Masters in IS in 2016 and completed three classes before leaving Apple and losing my tuition assistance benefits.
I had transferred my AS in nursing to SNHU, with a goal of completing a BS in IT, but after three years of taking one class a term with more then a few terms off in order to focus on Apple, I still had at least 1 1/2 years left to go.
I began prepping in October of last year and am proud of myself for sticking to the 15 hour a week study/prep plan I produced; I I am officially registered for the April 26th 2020 Graduate Record Examination!
To Inspire Evidence
We are at the precipice of the Fourth Industrial Revolution, which will commence with the arrival of true 5G in the mid-2020s upon the completion of the first micro-satellite networks that will exponentially drive data analytics and machine learning AI capabilities past the physical limitations of Moore’s Law; the transition from Documents to Data will be sustained through the adoption of complex predictive health monitoring analytics derived from evidence-based practice(EBP) approach methodologies for cloud-native-to-hybrid infrastructure sustainability with an emphasis on prophylactic operational failure interventions vs. the reactive mentality of today.
The mass, almost overnight, introduction of EBP into the world of software engineering will see the merging of site-reliability and systems engineering teams into one, similar to DevOps, but with an interdisciplinary twist. Instead of former sysadmins and ops engineers, SRE/Systems Engineering teams will be comprised of engineers and analysts turned coders from every non-computer science discipline, e.g. biology, education, social sciences, legal, and even the creative arts.
The exponential speed of the Fourth Industrial Revolution will touch every industry so fast that the traditional schools of thought on computer science and software engineering will be rendered inert in the face of the interdisciplinary scientific frameworks of inquiry required to establish the metrics and KPIs of the coming years…
EBP opposes tradition, but, at its heart, it is not conclusive or definitive about which course of action to take; instead, practitioners of empirical software engineering apply EBP for insight into the state of things at hand with the end goal of providing decision-makers with quantifiable evidence to enable scientific inquiry, analysis, and interpretation through deductive and inductive reasoning.
My place in this emerging trend is to encourage, support, and and celebrate both the successes and 'good trys' of team members that are naturally inquisitive and seek out evidence that can be used to implement new metrics and KPIs for an org through tailored Python data analytics reporting; there will be holdouts, but the collective drive to succeed or fail together is key to inspiring those reluctant to change.
I have already begun to experiment with new and innovative ways to implement metrics and KPIs at the most granular of levels with Python; though preliminary, and I def could be wrong, but I feel that this work will prove pivotal in the coming years.
My best work has always been inspired by the innovative and badass automation I once saw DevOps engineers do in G Suite; I will never be able to duplicate their work, but I strive to mimic that same ‘wow factor’ response in the things I automate and create. If nothing else, I would want to inspire that same creativity and problem-solving ingenuity in others.
To Enable Diversity & Inclusion
To Align Governance
To Coalesce Human Perspectives
To Uphold Respect
To Empower Reporting
To ❤️ Skunk Works
A - Z
- Evidence-based Practice(EBP): Any practice that relies on scientific and mathematical evidence to form strong inductive or deductive arguments for guidance and decision-making. Practices that are not evidence-based may rely on tradition, intuition, or other unproven methods.
- Evidence-based Software Design(EBSD): A personally coined term that is fully interchangeable with Empirical Software Engineering(ESE) that denote the exact same thing/idea.
- Empirical Software Engineering(ESE): Is a research area concerned with the empirical observation of software engineering artifacts and the empirical validation of software engineering theories and assumptions.
- Software Engineering(SE): the creation and maintenance of software. But from a research perspective, software engineering is the body of knowledge about the creation and maintenance of software and about the phenomena underlying and emerging from those two activities.
- Post-Mortem Analysis(PMA): An empirical study method in software engineering. It is an important, but often forgotten, way of gathering empirical knowledge. PMA is ideally performed either soon after the most important milestones and events or at the end of a project, both in s uccessful and unsuccessful software development projects. The benefit is that post-mortems can often reveal findings more frequently and differently than project completion reports alone.