Stanford's Jeremy Utley reveals that "most people are not fully utilizing AI's potential." Why is that? He explains that it lies in how we approach AI. He said a simple mindset shift could be what you've been missing in the AI revolution.

Creativity is doing more than the first thing you think of

Think of LLM as a teammate and not just a tool. Provide it feedback! Let it ask you questions!

Key Insights:
📌How treating AI as a teammate rather than just a tool can dramatically improve outcomes
📌Why you should have AI ask you questions instead of just answering yours
📌How non-technical professionals can leverage AI to achieve extraordinary results
📌The difference between treating AI as a tool versus as a teammate

00:00 Intro

If you want to learn more about creativity using AI with Professor Jeremy, please refer to the link below!
👉 https://www.jeremyutley.design/ai-newsletter

Perl came for free. How much have I contributed in return? Absolutely nothing.

I work as what I’d call an inside-contractor.
I’m a speed-dial (is that still a thing?) phone call away.
Occasionally, a client will call me a dozen times in a day.
I’m closer than their coleague in the next office.

We have decades of experience trying to automate processes. The biggest lesson is that automation is not about the easy and known flow, but about exception handling.

The best diagnosis for exception handling I can think of is to wait on line at the post office. If you’ve ever done that, you know the thought of “doesn’t anyone just want to mail a package” comes to mind. As it turns out the entire flow at the post office (or DMV or tax office) is about exception handling. No amount of software is going to get you out of there because it is piecing together a bunch of inputs and outputs that are outside the bounds of a system.

The ability to automate hinges not just on the ability to know the steps to take for predefined inputs, and not even the steps to take if some inputs are erroneous or incomplete, but what to do if you can’t even specify the inputs.

My favorite example of the latter is how the arrival of IBM computing in the 60s and 70s totally changed the definition of accounting, inventory control, and business operations. Every process that was "computerized" ultimately looked nothing at all like what was going on under those green eyeshades in accounting. Much of the early internet (and still most bank and insurance) look like HTML front ends to mainframe 3270 screens. Those might eventually change, just not quickly. It might be that the "legacy" or "installed base" of many processes is such that the cost to change is too monumental.

https://news.ycombinator.com/item?id=41765594

The feedback we get from users is not what it seems! As software creators we apply a lens that makes us take user feedback in many different - often unhelpful - ways from how it was intended. Here's a list of user feedback myths to help jog assumptions.

For tech and AI talent, jobs at financial services companies are more desirable than they have ever been. Banks have been working hard to make it happen.

The 70% rule: If you’re roughly 70% happy with a piece of writing you’ve produced, you should publish it. If you’re 70% satisfied with a product you’ve created, launch it. If you’re 70% sure a decision is the right one, implement it. And if you’re 70% confident you’ve got what it takes to do something that might make a positive difference to the increasingly alarming era we seem to inhabit? Go ahead and do that thing. (Please!)

70% is actually better than 100%

Moving forward at 70% takes more guts, more strength of character, than holding out for 100%, because it entails moving forward amid uncertainty, anxiety, and the disagreeable feeling that comes with putting less-than-perfect work into the world.

Why LLMs will transform development but not how you think

it's about how AI tools are enabling a new category of software that simply couldn't exist before.

When someone can describe their specific needs conversationally and receive working code in response, the economics of personal software development shift dramatically.

Think of it this way: just as spreadsheets enabled non-programmers to perform complex calculations and data analysis, AI-assisted development tools are enabling non-programmers to create personal software solutions.

When giving feedback on presentations most of us are unsure what to say and how to say it without upsetting anyone. That is why I designed a set of cards that you can hand out to your audience before…

1. Messaging: the message of the talk and the call to action.

2. Clarity: how easy the talk was to understand and follow.

3. Credibility: whether the facts and arguments presented were believable.

4. Engagement: which parts were more engaging, and which less.

5. Voice: pitch, quality, tempo and pauses.

6. Language: the type of language used and variety in expression.

7. Physicality: the speaker’s body language, gestures and movements.

8. Visuals: the quality and effectiveness of any visual aids used.

9. Connection: the speakers rapport and connection with the audience.

Shifts in the book industry have been a boon to writers who work quietly behind the scenes

3. I need you to play on your own for some time.
4. Let's compromise.
5. I need you to do this first. Then, we can do X.
6. While I trust your judgment, I still need you to follow some rules. We can discuss them together.
7. I cannot agree to this. You have to meet me halfway on this issue.
8. I need some more time to process this. Let’s revisit this later after I have had a chance to think about it.
9. We know you mean well, but we are different. Can you respect the difference?
10. This is what I need.
11. I respect what you want, and I understand it. Unfortunately, I am not comfortable yet saying yes.
12. I need you to help me.
13. I understand you are doing something, but I need you to X.
14. I understand you need my help, but I cannot work on this right now.

paul buchheit on the advent of gmail, insurgents vs. gatekeepers, the future of san francisco, ai,

An insurgent is never going to be successful working for gatekeepers, because from the gatekeeper perspective, the person just lacks maturity. They're doing these things that are obviously risky. That's the nature of throwing bombs: you don't exactly know what's going to happen.

Famously, we had one line of JavaScript in the entire product, which was when you go to the homepage, there was one snippet of JavaScript that would put the focus in the search box. That was the only JavaScript at Google. So Google had this kind of anti-JavaScript thing, that was also partially technical snobbery. One of the senior technical people said, “You can never scale anything in JavaScript, it’s basically just shit, the project will just turn to garbage.” And actually Eric Schmidt even said, “Oh yeah, my friend at some other big company tried this, it doesn't work.” There was a lot of ‘This has been done before, you just don't know why it can't work.’

Gatekeepers are one hundred percent anchored to stopping bad things from happening, and they have no concept that when you stop bad things from happening, you are inherently stopping good things from happening as well. You can't ever deliver something that's 100 percent good. If you deliver 80 percent good, that's pretty good. But if you try to go for 100% — if you try to be perfect — what you get is nothing. Innovation is inherently not clean.

A manifesto on work, waste, cost and value.

Work in progress has zero value. Ship!

• Before a task is shipped it provides zero value.
• Any work in progress is pure cost.
• Two tasks in progress adds cost, for no value.
• Only after shipping do you create value. Always ship.
• One task shipped is infinitely better than 4 tasks “almost done”.
• Ship something of value first. Then begin something new.

AI cannot develop software for you, but that's not going to stop people from trying to make it happen anyway. And that is going to turn all of the easy software development problems into hard problems.

• A computer can never be held accountable. Therefore, a computer must never make a management decision.

Programming as Theory Building

Non-trivial software changes over time. The requirements evolve, flaws need to be corrected, the world itself changes and violates assumptions we made in the past, or it just takes longer than one working session to finish. And all the while, that software is running in the real world. All of the design choices taken and not taken throughout development; all of the tradeoffs; all of the assumptions; all of the expected and unexpected situations the software encounters form a hugely complex system that includes both the software itself and the people building it. And that system is continuously changing.

To circle back to AI like ChatGPT, recall what it actually does and doesn't do. It doesn't know things. It doesn't learn, or understand, or reason about things. What it does is probabilistically generate text in response to a prompt.

You have to be willing to step into the unknown if you want to be creative.

The will to do things that haven’t been done before.

When we’re creating things that have not been done before, uncertainty is inevitable.

The willingness to stay in the question long enough for the dots to connect.

My inability to make decisions is frustrating, but it also allows me to stay in the question longer. I’m not rushing to find a quick fix but rather twisting and turning problems. I often find the need to go back and research some more. To make sure that the path I’ve decided to take is the right one. It wasn’t until I got more comfortable in my role as a designer (I wish I could say that my imposter syndrome went away, but it still surfaces in every project) that I discovered the benefit of this. When it comes to solving problems with creative solutions, we must first spend time figuring out the right problem to solve. Then make sure that the solution we propose is helping more than hurting.

It’s never too late to control your own fate

In my way of thinking, radical agency involves finding real edges: things you are willing to do that others aren’t, often because they’re annoying, unpleasant, or obscured in a cloud of aversion.

The idea of finding real edges, rather than eking out wins by grinding harder than everyone else, clicked for me when I started playing poker. Pros spent nearly as much time studying as they did playing, using solvers to seek out tiny mathematical advantages. I noticed a massive edge that was almost entirely ignored: physical reads, or tells.

Court rejection

Seek real (anonymous) feedback

Increase your surface area for luck

Assume everything is learnable

Learn to love the moat of low status

Don't work too hard!

Negative engineering is the time-consuming and sometimes frustrating work that engineers do to ensure small bugs don't take down systems.

There were no warnings or red lights, because the process simply hadn’t run in the first place. And so a new, time-consuming activity was added to the data analytics stack: manually checking the database each morning to make sure everything had functioned properly.

Negative engineering is “insurance as code”

Negative engineering is the time-consuming and sometimes frustrating work that engineers undertake to ensure the success of their primary objectives.

A new set of principles for better workflows when making digital products

“Ready for dev”

It’s safe to say that there is a natural tension between the fields of design and engineering. Traditionally, the role of design is to question, create meaning, and to argue for solutions that make for a better user experience. The role of engineering is to systematize, solve technical problems, and to argue for solutions that make for a simple, scalable, and future-proof implementation. The design process begins before we know what we want, and engineering usually happens when there is a clear notion of what is being built.

"Unfortunately, these projects often do more harm than good if the organization uses the design system as yet another initiative to centralize the decision-making process..."

1. Flatten your waterfalls
2. Make code the design product
3. Operate like an open source project
4. Increase visibility through automation
5. Plan like a farmer

​ ​ ​ Hey [FIRST NAME GOES HERE], Have you ever noticed how some people seem to get all of the press and attention even when other people have built something similar? It can be...

If you work in a 500-person company, even if you’re junior, you can gain attention by writing. You just need experience and ideas to write about, but you don't need authority or influence. Let your ideas speak for themselves.

Write about what you’re learning or strategies your team can pursue, and share it. People can comment on what’s interesting, or even disagree, but either way, you’ll increase your attention and influence.

Writing automatically elevates you from the sea of other people doing the same thing.

David shares a compilation of the best links from his newsletter Friday Finds. Read here.