HN user

cpb

35 karma

[ my public key: https://keybase.io/cpb; my proof: https://keybase.io/cpb/sigs/_8rT1Oz5NrEFkqZWpOuAOyAR6V8UgnS9jlpv1eReUHM ]

Posts0
Comments36
View on HN
No posts found.

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?

The second brain is emerging out of this. I keep these notes as a sibling project to all the software projects I'm interacting with.

When shooting my shotgun for finding more references, what I've done/know/questioned about a piece of code shows up too.

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.

Is it to spare keystrokes in method definition, or rather, in method invocation?

Your second definition reads that `with_longer_parameters` is a keyword argument with no default.

Still, you've illustrated the keystroke savings with your choice of parameter names :-)

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.

May we be so fortunate to choose.

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?

How do these services make it easier to evaluate data? The medium article starts with a disclaimer about DLT... Talking with investors buying data, one shouldn't be surprised to hear them request uploads to their FTP. Their data teams are overcommitted when it comes to the evaluation side of consuming data. They aren't (yet) resourced like a tech startup.

How should they prioritize learning about ingesting data from a DLT? They have data brokers (like Quandl) coming to them with assurances of frictionless integration, with data they can understand and use, today!

The effort to evaluate the null hypothesis can be costly. In the competitive environment found in most hedge funds, how would you allocate to accepting the null hypothesis?

As in, if you worked at a data acquisition desk, and spent a quarter churning through terabytes of null hypothesis data, what's your attribution to the fund's performance?

In an interview, Ryan Caldbeck from Circle Up describes two categories of models: brainy models and brawny models. The ensemble described above sounds like a brawny model: you don't care how it made the decision, you're glad it did the heavy lifting and you might even double check the result.

However, the user's concern about the black box suggests they wanted what Ryan refers to as a brainy model, one with explicable decisions. Even within the features of the model there could be things to learn about the data.

How else are data scientists stuck within their own world?

Maybe they wished they had preferred shares? There are better vehicles for this, worked out far in advance of the liquidity/change of control. You shouldn't be surprised by the actions or requests of a shareholder during an acquisition.

Does your shareholder agreement include a "drag along" clause? What percentage of shareholders are required to vote in favor of the acquisition? I would check to make sure they can't screw up the vote if you don't take their (a bit worrying) offer.