I want to support some colleagues with automating some of the setup of routine video editing. Can't consider this impressive work without that clarity!
Could you go into more details about the errors you encountered along the way?
I tried having ChatGPT do TDD to vectorize n-ary trees, but it made mistakes that indicated it didn't understand it's output:
- the expected vectors in the tests were the format it suggested for binary trees
- when asked to represent a vector
as a tree, produced one correct tree and another incorrect tree. (Correctness as determined by how it chose to encode a tree as a vector).
It took some iterations to get it to fix the tests, but I grew weary of coaching it through each of the problems as we encountered them. Maybe if I was at my keyboard rather than on my phone I could have had it complete the task quicker.
So, what errors did you encounter along the way? How did you overcome them?
Having tuned in a few times to watch https://twitter.com/AdamLearnsLive on twitch, I was inspired to take notes throughout my development process. What I noticed of Adam13531's note taking was they wrote down every question that came to mind as they worked down the rabbithole of learning that is software development.
For my own practices, I've added in a bit of an OODA loop process. My intent is to systematically balance between deciding and executing, focusing on accumulating knowledge towards achieving a goal.
When I'm stuck, or dealing with unknowns, the brainstorming in each of Observe, Orient and Decide enable me to gain some flow.
Later, I can observe where I had blindspots, or anchored to certain contexts or scopes. I'm noticing I could develop checklists to go through to avoid repeating those biases.
I'll add to the voices here mentioning vulnerability. I believe it takes strength and courage to choose vulnerability.
I am starting to recognize that the courage is required because it can be a filter. It isn't just the chance that a "nurse or phlebotomist" might judge you harshly, there are many people in the world that'll sooner reject than connect with you.
Still, if we are to be true to ourselves, perhaps vulnerability can minimize the total amount of pain in our lives. It'll take weighting the acute pain of rejection as vulnerable as lesser than the chronic pain of acceptance with insecurity.
I really connected with the writing. Thank you for taking that time.
There is a lot in my current context the writing resonates with. Nice to find that others have been on this path too, and that we benefit from a lot of the same techniques.
Thanks for putting this out there as an invitation to draw people together.
The first book I read about sales emphasized inquiry before advocacy. Let's get real or let's not play by Mahan Khalsa.
I read it at a point in time for my startup when we had done as many Customer Discovery interviews as we could in our local market, and were trying to achieve a first sale or pilot project with customers in more innovative markets. The inquiry phase of solution selling connected with and reinforced the customer discovery process, but provided some indication of how to move forward, and cautions about moving forward too early with a proposal.
The key to sales is solving problems. You claim to have a product that addresses a large "potential" - what problem, and for who, does it solve? Can you measure the impact of the solution?
If you have a product that solves a problem, what is the least intrusive thing you can ask of a potential customer for you to identify if they perceive they have that problem, and if they recognize the impact of solving it?
If you cannot mutually identify the problem and impact of the solution, a prospect may only entertain your talkative nature to solve the problem of looking busy to their superiors.
Track the observable characteristics of your prospective customers that are the best indicators of if they have the problem you solve, or not.
Figure out how long it takes you to identify if they have the problem, or not.
All my mentions of issues or friction in my previous comment was about pre-k8s team's experiences... I try and clarify a few key cases in the following:
> Successful utilization of k8s, interesting metric, what is your criteria ?
Sorry, what pain motivated using k8s, and using k8s relieved that pain.
> I have seen properly staffed startups (in silicon valley)
What is 'proper' for staffing?
>> Are your SRE shipping the new features, or running like a red queen to keep the product developers able to keep shipping?
> Yes to both
Is it the appropriate use of a Reliability engineer's skills to develop or change arbitrary features? Or are you saying they are at least Engineers so they should be able to pitch in everywhere... CSS accessibility features or k8s config.
>> What development process or cycle has overheated with friction that requires k8s?
> Upgrading k8s :)
This tautology keeps me away from k8s. Before k8s what pain in the process required using k8s to solve?
> a pipeline getting product to production fast
Does k8s make it fast? Does k8s make it possible? I think I'm deploying "fast", without k8s... But because you keep mentioning ITIL I suppose it's more about the infrastructure changes? Or are you talking about ITIL tension because k8s requires a more liberal policy than ITIL allows?
There is so much assumed context when talking about k8s, the only comprehensible part of these discussions is k8s is a rabbit hole to end all rabbit holes.
In your experience, what is the strongest point of evidence leading to the successful utilization of k8s?
> the company has a marketing team driving new development that needs to get to market fast
At what point in the growth curve? Are your SRE shipping the new features, or running like a red queen to keep the product developers able to keep shipping?
What development process or cycle has overheated with friction that requires k8s? Where is that friction which k8s relieves?
I want to support some colleagues with automating some of the setup of routine video editing. Can't consider this impressive work without that clarity!