- What is Crisis Informatics?
- What are the principles on which NetHope was founded?
- What insights about good service can you gather from Ed’s writings?
Friday, October 11, 2024
HappGPT Chatbot Test
Wednesday, October 9, 2024
ABC Resilience
I asked the new AI Chatbot my students are helping develop, based on the information provided in my Crisis Informatics course. Following some iteration through multiple drafts, here's what HappGPT had to say[1]:
Hurricane Ready: A, B, and C Plans for Navigating Uncertainty
Hurricanes pose a significant threat to coastal communities, bringing devastating winds, torrential rains, and storm surges that can wreak havoc. While we can’t control the weather, we can prepare for it. A critical component of community resilience is ABC planning, which outlines a three-tiered approach for responding to hurricane events:
A-Plan: The Ideal Scenario
The A-Plan outlines the ideal response to a hurricane threat, assuming ample time for preparation and readily available resources. This might involve:
Early Warning System: A robust system for receiving and disseminating hurricane warnings, including local broadcasts, community alerts, and social media communication.
B-Plan: Adapting to Challenges
The B-Plan is activated when the A-Plan becomes impractical due to changing circumstances, limited time, or resource constraints. This might involve:
Adaptive Evacuation: Adapting the evacuation plan to accommodate the changing situation, perhaps with shorter evacuation times or different routes.
C-Plan: Navigating Chaos
The C-Plan is not just a backup plan; it’s a framework for navigating decision-making in the face of uncertainty and chaos, after the A-Plan and B-Plan have failed. It’s about establishing a process for making critical decisions in a fluid and unpredictable environment. This might involve:
Decision-Making Processes: Pre-determining a decision-making hierarchy or structure for critical situations, including roles and responsibilities.
Personal Go-Kit: Your Individual Resilience
While community-level planning is essential, individual preparedness is equally crucial. Building a personal “go-kit” can significantly enhance your ability to survive and thrive during a hurricane:
Back-up Communications: Include a weather radio, a hand-crank radio, and extra batteries. Consider a satellite phone or a two-way radio for communication when cell service is down.
The Power of ABC Planning and Individual Action
By developing comprehensive A, B, and C plans, communities can strengthen their resilience, minimize damage, and ensure a quicker and more effective recovery process. Additionally, by building a personal go-kit, individuals can empower themselves to face a hurricane with greater confidence and preparedness.
ABC planning, combined with individual preparedness, fosters a culture of readiness and empowers communities to weather the storm and emerge stronger than ever before.
______________________________
[1] A beta test version of HappGPT has been posted to this Blog, here: https://eghapp.blogspot.com/2024/10/happgpt-chatbot-test.html . Please pose your follow-up questions there and leave comments on what's working well and not so well.
"The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated."
Monday, March 20, 2023
Book Projects
- Letters to a Young Manager (a book of stories with collected wisdom for the new manager, be it project leader, supervisor or department manager) - http://www.hpmd.com/hpmd/personal/LTYMstories.nsf/vwBook?OpenView
- We Are Better Together (NetHope Memoir) - http://collaboration-book-project.blogspot.com/
- Crisis Informatics Management (from the SI-537 class) - https://docs.google.com/document/d/12ULKaMl4-MD8rYOSADHhmWfSTllc2uv5PBOah5UoM8w/edit?usp=sharing
- IT’s About the Conversation (from the SI-627 Class) - https://docs.google.com/document/d/1rKh7jVeP0naPfP-tliAiHb9h06_pvGJvefuB5tcMCsQ/edit?usp=sharing
- Project Management Proverbs (from discussions with student cohorts working on the Data4Good Center, https://www.data4good.center/ ) (TBD)
- The Consultant Mindset (from SI-345 lectures and Data4Good weekly meetings) (TBD)
- Online Team Exercises, or Games Zoomers Play (exercises from my classes) (TBD)
- The Soil of Heaven (collection of Lenten and other poems) - https://poetryworkbook.blogspot.com/2014/07/the-soil-of-heaven.html and https://poetryworkbook.blogspot.com/2022/03/lenten-poems-2022.html
- Experiments in ChatGPT (posing questions to OpenAI's ChatGPT and commenting on some answers) - https://docs.google.com/document/d/1eQ9eUE3bxa9vEemi2WxSQcqs0SN3JjmscgHF8ykCgWI/edit?usp=sharing
"The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated."
Monday, January 2, 2023
A Personal Introduction in Five Chapters
Saturday, December 3, 2022
The 3x3 Summary
The 3x3 critiques are designed to practice summarizing content for presentations and for senior managers. It’s a very important skill to have in corporate settings, both for-profit and nonprofit. Most executives do not have time for the details; they want to know what the “bottom-line” is and what questions they should be asking.
What is it?
Each reading for a given week is to be summarized with 2 slides:
- 3 takeaways
- 3 questions
- Minimum 20 point font and standard 4:3 (8.5 x 11 inch) slide formats (if you elect to submit a text doc, limit yourself to one page per reading for both takeaways and questions; 150 words per page total)
- PowerPoint, Google Slides or PDF are acceptable as a file attachment
Why?
- The importance of finding the bottom line. See my Blog post: http://eghapp.blogspot.com/2011/07/finding-bottom-line.html
Instructions:
Here are some further clarifications:
- The 3x3 Takeaways/Questions should be done for each reading assigned and not the aggregate
- The questions should be a critique of what you read, things you would challenge the author about, or the organizations cited. Put yourself in the mindset of a consultant; what would you recommend the senior management team think about? Put this into your questions.
- You may choose a set of weekly readings already done, but the takeaways and questions should be unique (i.e. Unique from what was presented in class or from colleagues).
- Include chapter or page number(s) references for each takeaway (where available)
- Include a title slide or header indicating your name, course name, assignment name, date, and the week for which you are summarizing the readings
- You may use more than one sentence/phrase/related-question in each item
- Assignments should be submitted online in Canvas.
- One critique is due for each month of the class, at the end of Jan., Feb, and Mar. There is no critique for Apr.
- Note the 5% penalty per day late on assignments
Presentation Elective
- If you volunteer to present a readings summary in class, please do it for all of the readings, two slides per each (in PowerPoint please). Note that this counts twice: once for the elective and once for the weekly critiques. Please submit it in both places in Canvas.
- For the in-class presentations, email your daft slides no later than 48 hours before class starts, so that we can iterate as needed.
- One additional step for presentations: choose a maximum of 3 questions from among all those in your summaries to discuss in the team breakouts.
- Plan on spending no more than 2 minutes per slide summarizing, and 10 minutes for discussion.
- Note that no matter which format you choose for a reading summary, for presentations, I will be copying it into PowerPoint slides so it is part of the class deck. Please verify it works in that format.
- Highlight the most important phrases on each bullet/slide (underscore or color) so that the key talking points stand out from the text, and so you refrain from reading your slides.
- Starting mid-semester, we will switch to a one-page critique and shorter presentation. Please see the rubric linked above for this change. Note that the monthly submissions will remain in the 3x3 format.
- See the Q&A section below for additional clarifications.
Discussion
This rubric applies to the 3 required weekly reading summaries and to the in-class 3x3 elective presentation.
The critiques are 100 points each; max of 3 for 300 total points; you pick which 3 weeks, but one is due each month. This will be listed as 3 assignments in Canvas, in the Weekly Critiques section.
Note that whoever volunteers to summarize the readings and present these in the class can work off this assignment and get double the credit for that week. However, no repeats on the presentations!
Grading
- Content (Two slides with 3x3 summary) (40%)
- Succinct (Chars <=700 per slide, +/- 20%) (10%)
- Format (Min 20 pt font, 8.5x11 slides) (10%)
- Uniqueness (30%)
- Writing quality (Clear, Correct, Coherent, & Compelling) (10%)
- Minus Penalties (Lateness) (-5% per day)
- Plus Optional Readings (10 points for each)
Example
From the first reading, presented in week 1
Ed Happ, Week 1, Jan. 6th readings
Nicholas G. Carr, IT Doesn’t Matter, May 2003
Takeaways:
- IT is following the adoption curves of other utilities, becoming pervasive and cheap
- IT therefore no longer offers any competitive advantage
- As a result, organizations should spend less on IT, and wait longer to purchase
- Where on the IT stack does Carr focus? If infrastructure is a commodity, what of business apps and consumer apps?
- Is strategic limited to the unique? What of mash-ups? Operational excellence?
- Is IT a utility or a way of doing business? Is the digital enterprise more fundamental?
1) Do the 3 critiques in the syllabus refer to the week or individual readings?
a) The three critiques refer to three weeks of readings, not three readings in a given week. There are multiple readings each week. I added the word "week" to the description in the syllabus and rubric to clarify this.
2) What does “bottom-line” mean in this context?
a) Bottom-line is a common business term that comes from financial reporting; the bottom line is usually the profit, which equals the total revenue or income less the total costs, which is literally the bottom-line on a financial statement.
b) Bottom-line for narrative documents or presentations is usually the summary conclusions, or “headlines” of the document. It is characteristically succinct.
c) For these 3x3 summaries, we are defining “succinct” with a digital yardstick: as 3 tweets (plus 2 for headings, references). So a succinct 3x3 slide means 700 characters or less (5 * 140). That’s hard to do but important in communicating at the senior levels of an organization.
"The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated."
Saturday, June 5, 2021
Handling Ambiguity
The following is an excerpt and case from one of the classes I teach in Crisis Informatics.
This is a story that relates to this and is one of my favorite experiences. I went to a cooking class with my wife in Varenna, Italy. We were staying in Bellagio and took the ferry over across Lake Como and then took a taxi cab up to this restaurant on the top of the hill, over Varenna where we met our host. I called him Professor Marino, because he was the chef who was teaching this class and this day he happened to be teaching in English. He taught it in certainly in Italian, and may have taught it in French also. But I called him Professor Marino because he was a bit of a philosopher, as you'll see. So, the group that was there for the class, we were told we were going to make gnocchi. So, the first question, we asked him after he took and he poured a whole bag of flour onto the table. And he made like a volcano shape out of it. And he put four eggs in the center. And then he starts mixing it with his fingers. And he's mixing the dough and mixing the dough. So, the first question was, how can you tell if the dough is mixed enough? And he said, close your eyes and touch the dough. Think of something beautiful and touch the dough. And you'll know when it's ready. Of course, if you've done it many times before you know when it feels right, because you've been there. And the next thing he does is he starts rolling out the dough with his rolling pin. And then we asked the next question, Well, how do you know when the dough is thin enough? And he says, you can see the grain of the table, the grain of the wood will show through the dough and that's how you know that it's thin enough. Now, he said, in Italian cooking, for most dishes, you need to taste and adjust, taste and adjust, taste and adjust. It's an inexact method. And he said that's true for most every Italian dish you make, with one exception. Italian pastry. For Italian pastry, he said, you must follow the recipe, you need to have the ingredients exact, you need to have the temperature in the oven exact, you need to have the time that it's in the oven exact, otherwise you ruin the pastry.
So, an interesting question to consider, and applying this as a metaphor: is most of business, including technology, about making pasta, or pastry? [dramatic pause]. It's about making pasta. In other words, it's handling ambiguity. So, if you prefer to work with a pastry approach and have an exact recipe, you're going to get very frustrated in your business career. Learning how and developing strategies for dealing with ambiguity will help you navigate that transition. Things at the university tend to be fairly exact. Rubrics are fairly exact. Exams are exact. But work that we do in corporations, in nonprofit organizations, and governments tends to be rather inexact. And there's a fair amount of discovery, experimentation and exploring, that you just plain have to figure out. That's a challenge.
So, why is it important to be able to handle ambiguity? Well, everybody in leadership expects you to be able to handle the ambiguous situation. And ambiguous projects, especially when they're projects from clients. These have a greater probability of being ambiguous.
Your initial encounter with client ambiguity may come during your interview for the job. I'll illustrate this with the Amazon Interview case, below, where the candidate was deliberately asked ambiguous questions to see how they would handle it, to see what their thought process was, how they broke it down, and made sense out of it. Because when you're doing client projects, that's the thought process you're going to need to follow. It's also an opportunity to prove your value-add at times. How do you make sense out of the chaos? Can you demonstrate that?
The Amazon Interview Case
A question was posted on Quora.com, presumably in Dec. 2016 [3], by a developer who had applied to Amazon and did not pass the on-site interview. They asked Quora readers for advice about what to do next. One of the responders was Matt Kellner, a software engineer from the Seattle area [4]. 1.5 million people have read his answer to-date.Matt indicated in the follow-up comments that he previously worked for Amazon, and that he has been on both sides of the interview table. He notes that the line of questioning where an interviewee “locked up” is typical at tech companies. It’s deliberately ambiguous. It creates a mini-crisis to see how the applicant handles it. Read his response in full, below.
Also read the other replies, as there are interesting perspectives on tough interview questions. The bottom line is that companies are looking for candidates who can handle ambiguity. It’s not only for solving open-ended problems internal to the organization; often customers do not know exactly what they want and are not particularly adept at providing focused requirements. In fact, one could argue that in the realm of customers, whether internal or external, perfect requirements don’t exist. So handling ambiguity is fundamental to tech-related work.
Here are the discussion questions:
- Have you encountered ambiguous questions during interviews? How have you handled them?
- What do you think about Matt’s advice on how to handle ambiguous questions? What resonates and what doesn’t?
- If the goal is to have a successful job interview (i.e., generate an offer of employment), how will you handle the inevitable ambiguous or open-ended question?
- What do you find frustrating about this, and how do you propose to deal with that?
- If a goal of crisis preparedness is to build more resiliency, or the ability to “bounce back”, how will you prepare for the interview crisis?
Here is the Quora.com excerpt:
What should I do after failing at
Amazon's on-site interview?
This question previously had details. They are
now in a comment.
11 Answers
Matt
Kellner,
Software Engineer, Video Game Historian and Part-Time Farmer
“I wouldn’t call you a “loser”[5], but it does sound like you did one thing that interviewers don’t like to see in technical interviews. When you get a technical question in an interview, that question is almost always going to start out vague - it’ll have some important pieces missing such that you actually CAN’T adequately solve the problem without more info.
In a case like that, the interviewer is
being very deliberate about the ambiguity. They may be simulating a request
from a customer where the customer knows what they want but didn’t do a good
job of communicating it. The point here is to see how you handle ambiguity: Do
you make assumptions? Do you lock up? Do you go down a path toward a solution
without understanding the question? Or do you try to identify what you don’t
know and start asking questions to clarify?
I’ve interviewed a lot of people who
did what you described: They just stood there staring at my question, not
talking at all, not letting in on their thought process, etc. The problem is,
you might be thinking through the problem, but the interviewer can’t tell what
you’re doing, so to them, it looks like you just lock up.
We generally understand that people get
stage fright in some situations. The interview is a stressful, grueling process
for most people, so it’s not surprising that you’d have a case where you just
lock up - some people don’t even realize they’re doing it. That’s why a good
interviewer will try to prompt you, will ask you to describe what you’re
thinking, will give you small bits of guidance, etc.. We WANT you to succeed,
and it’s in our best interest to do whatever we can to help you succeed.
But there’s only so much we can do. If
it becomes obvious that you’re completely lost on a problem, or you have to be
hand-held through the whole thing, or you’re just not going to “perform” no
matter how much help we give, that’s not a good sign of how you’ll do in a real
work environment. The real work environment, especially at Amazon, is often
more stressful and faster-moving, and your success or failure on a real problem
could make the difference between success and failure of the product you’re
working on.
So, here’s what I always recommend to
interview candidates:
·
Brush up on your problem-solving
skills. Remember that most interviews are about how well you can understand and
solve problems, not just how good your code looks.
·
Always, in some way, repeat back the
question you’re asked. It’s up to you to decide how best to do this - you can
paraphrase the question, you can draw a diagram on the board, you can describe
it in terms of behaviors, etc. But make it clear that you do (or do not)
understand what the interviewer is asking you to do.
·
If you find a point where you CANNOT
do that, ask the interviewer to clarify. For example, if I ask you to divide
two numbers, and you realize that I haven’t specified what should happen when
the second number is zero, just ask me - something like “What should this
method do when I try to divide by zero? Throw an exception? What kind of
exception should we throw?” etc.
·
When the interviewer clarifies a
question like that, you might then realize you have even more questions.
Explore those. Take notes on the board as you get these clarifications, as they
will inform your solution.
·
Keep things moving. Keep talking,
think out loud, draw, write, whatever you need to do to keep your interviewer
informed as to your thought process.
·
Finally, don’t worry about finishing
your solution. Most of the time, it’s not about actually writing and fully
testing a finished piece of code - if you get there, that’s great, and a good
interviewer will probably add a bit of complexity, quiz you on testing or on
the operational complexity of the solution, etc.. But most of the time, they’re
more interested in seeing how you approach problems, how you think and how
willing you are to reach out for help. (This includes cases where you know what
you want to do but don’t necessarily know the correct syntax to do it in
whatever language you’re working in. If you can describe what you’re doing, the
interviewer can usually play technical reference for you.)
If it helps any, I’ve done a number of
interviews (on both sides - being interviewed and giving the interview) where
we never got around to writing a single line of code. Instead, we spent the
whole time just discussing the problem. :) I personally think those kinds of
interviews are the most fun.
Hope this helps. :) Last piece of
advice: Don’t be afraid to apply at Amazon again in the future. You’re unlikely
to have been “blacklisted” - let some time pass (say, 6 months or a year),
brush up on your skills, and if you’re still interested in trying again, apply
to new positions. I can’t guarantee that they WILL interview you again, but
they certainly might.
… I remember that
someone in the comments took exception to where I said “Instead, we spent the
whole time just discussing the problem”, as it seemed (to that person) that I
was saying interviews really are only about conversations and not technical. I
want to clarify this point:
What I meant there was that we
sometimes ask (or are asked) questions that are really huge in nature. For
example, in one of my own job interviews, I was asked how I would design a
banking system that could handle deposits, withdrawals and account transfers.
When I started exploring edge cases, concurrent users, data storage mechanisms,
account locking and fraud detection, etc., the scope of the problem blew up to
enormous proportions. What started as a simple exercise in defining some common-sense
interfaces for these individual functions turned into a wide-ranging discussion
that touched on both general banking concepts and on distributed systems
design. Given that where I work is concerned with such things, this was
on-point.
Once I was hired, the person who did
that part of my interview mentioned that he fully intended for the discussion
to grow like that, as the “test” he was giving me was on whether I would just
try to solve the direct problem, or if I would start looking at the “big picture”.
I’ve found in many cases that this is one primary difference between “junior”
and “senior” engineers - since I was applying for a senior position, this level
of discussion was appropriate.
My point here is to illustrate what is
meant by some interviews not involving coding, even though you may be
interviewing for a coding position. Software engineering, particularly the type
that Amazon does, entails a lot more than just basic problem solving and
algorithms. As you move up the chain, you can’t avoid taking on more in the way
of large-scale design, testing, project management and other things that you
may not be used to doing. And these interviews, in part, are done to see how
ready you are to step outside your comfort zone.
(Update 2, April 8, 2018) I was reviewing
this question and found another answer I hadn’t seen before, stating that you
should be happy that you didn’t get hired at Amazon, and linking to a Google
site documenting “management abuse” and such. I’d just like to say that, as a
former employee of Amazon, I strongly disagree with this person’s answer (they
disabled comments, so I can’t respond directly). While I cannot speak for all
departments at Amazon, I worked in a total of four of them while I was there,
most of that in AWS, and my experience there was nothing like the majority of
reports on that site.
There are a couple of groups at Amazon
that most people agree are less than ideal to work for, but my experience was
largely positive, and the difficulties I encountered had more to do with the
“frugality” aspect of Amazon’s culture - most notably in running “lean” teams
that do more work per person than at most other companies. But I was proud to
be a part of the groups I worked for - I did some of the best work of my career
(so far) in those groups - and I left the company on good terms and would
consider going back in the future.
I won’t tell you not to check out that
“FACE of Amazon” site, but keep in mind, it appears they have posted only
universally negative stories there, and thus the site seems to suffer from
confirmation bias. Their language and their use of an anonymous email system
suggests that they are not interested in positive stories for balance. If
you’re concerned about what it would be like to work at Amazon, I would encourage
you to look also at sites like Glassdoor to view ratings from a more representative sample of
current and former employees, as well as by job type and title.
In my experience, Amazon has very high standards
for its employees, and it CAN and WILL burn you out if you let it.
However, they do also respect you when you tell them what your limits are - if
you can still do your job, you should not fear letting your manager know that
you can only work 40 hours a week.”
About the
Author
Software Engineer, Video Game
Historian and Part-Time Farmer
Software Engineer1997-present
Studied at California Polytechnic State University, San Luis
Obispo
Lives in Puget Sound
[3] The earliest comment is from Dec. 8, 2016, after expanding all the comments,
here: https://www.quora.com/What-should-I-do-after-failing-at-Amazons-on-site-interview
. The original question posting does not appear to be currently available on quora.com.
[4] https://www.quora.com/What-should-I-do-after-failing-at-Amazons-on-site-interview/answer/Matt-Kellner-4, Last
Accessed on August 15, 2018
[5] See the comment by Heck Evergreen, Senior Software Dev Engineer in 3/10 Top Companies (2005-present), answered Jun 4, 2017