DEV Community: Ivy Puckett

A long list of weird things I've used in production

Ivy Puckett — Wed, 18 Mar 2026 05:07:06 +0000

I've been paid to utilize 80 different software tools in my 8 yrs as an engineer. I've gone deep on some (Go, Regex, SQL Server) and light on others (jq, Ruby). All of them have been interesting.

I learn two lessons from this:

Spend time on fundamentals. No matter where I find myself, I'm grateful I read "Software Architecture: The hard parts." I'm less grateful I read that book on C#.
Evaluate tradeoffs, not familiarity. Most tools do the same kinds of things. You can write the same app in JS and Rust. Pick the tools that fit your needs, not the ones you've used before.

The categories are illustrative vs comprehensive. I would not say HTML is a programming language for instance.

I've provided links to a couple niche tools I've found to be very helpful.

Runtimes
- Azure Functions
- Lambdas
- EC2 & ECS
- Azure App Service
- Kubernetes
- KEDA
- WordPress
CI/CD
- Azure Devops
- GitHub Actions
- Jenkins
- Terraform
- Cloudformation
- CDK
- GitHub
- Make
- Taskfile
- IAM
- SSM
- SecretsManager
Async messaging
- Azure Service Bus
- Azure Event Grid
- SQS
- EventBridge
- RiverQueue
- Temporal
Reverse proxies / gateways
- Azure API Manager
- Tyk
- NGINX
- API Gateway
Low-code
- Microsoft PowerAutomate and PowerApps
- Microsoft SharePoint
- Windmill
- Braze
API Documentation
- Bruno
- Postman
- Httpie
- OpenAPI
Load testing
- K6
- Vegeta
Editors
- DataGrip
- VisualStudio
- VisualStudioCode
- Neovim
- Helix
- IDEA
- Cursor
- Copilot
Languages
- SQL
- KQL
- XML (included because I have some war stories haha)
- PHP
- Regex (included because I think I'm more practiced than ~95% of devs)
- Protobufs (yes I've written these by hand)
- C#
- HTML
- JS
- Angular
- Ruby
- Python
- Rust
- Java
- TypeScript
- Go
- Cucumber
- WPF / .NET Framework / .NET Core
- SOAP (now that was hellish)
- ThreeJS (I was paid to make a procedurally generated 3D galaxy renderer. That was cool)
Database-like
- Athena
- SQL Server
- Oracle
- Postgres (best SQL db imo)
- MySQL
- Steampipe
- Azure Blob Storage
- Azure SQL
- DDB
- S3
- Goose
- EntityFramework

What tools have you used? I'd love to hear about them.

Photo Credit: The New York Public Library

7 Dumb things I'd do if I started a software company

Ivy Puckett — Fri, 21 Nov 2025 04:08:45 +0000

Life is short, be proud of your work.

1. I'd contribute to small companies

AWS is probably the right choice because of it's 5 9s of availability on its core services. I've been on the other side and I trust that when something goes wrong, someone is aware and actively working to fix it before I even knew about it.

...Also, I want to support a diverse cloud market so instead of making the right choice, I'd probably go with startups like fly.io, tigris, clerk, and lemonsqueezy... not that I've thought about this or anything.

2. Not use SQL

SQL makes modeling a small domain easier, but wow does it cause problems. I remember being at a company where engineers had to plan to wake up at midnight to upgrade various dbs to meet quarterly objectives. I don't want to ever have to wake up to upgrade a db.

At another company, all we did was debug indexing all day. Our schema was so awful that a single user could lock the whole 16k/month db for 20 minutes. And it wasn't an edge case, this is just something that happened about once a week when someone decided to update their filters.

It's well known that AWS avoids using SQL internally. I was exposed to the magic of this and I don't know why I'd ever go back. It was so much easier to predict performance because there weren't any noisey neighbors or weird query plans.

But, I admit, I don't have a good columnar store replacement in mind, so I might use Neon. They manage the upgrades and I can trust myself never to add a join keyword to my queries... Probably 😉.

3. Only deliver software over the internet

Delivering updates to native applications is painful. I've had to do it for both desktop and mobile and I don't want to deal with it any more. When a customer uses my product, they will always get the freshest version, no exceptions. This means a web interface and possibly a PWA if it's really necessary.

Unless I make a game.

4. Make the UI render without CSS

It makes accessibility easier and cuts down on the amount of bytes sent over the wire. Then after everything is in the right place, I might style the UI so it looks at all presentable.

How would I render a graph? No idea 🤷‍♀️

5. Have a fully static website and an API on day one

I worked in a dotnet framework app where the controllers rendered HTML. It caused a lot of security issues because there was often no meaningful distinction between what the client "was" and what the server "was." In a vacuum I'd expect it to be the opposite, but I learned then that separating the frontend makes things easier in the long run.

It's a stupid decision because even if it's more maintainable, it's more to maintain. Just should just use Ruby on Rails or something.

6. Use a monorepo

Monorepos make it easy to couple things that shouldn't be coupled, but as a solo dev, why would I want to make multiple commits to get out one feature?

7. Just use Taskfiles for cicd

CI/CD doesn't have the same return on investment for companies with less than 2 software teams. I've configured pipelines and stuff as a solo dev, but they always end up requiring too much maintenance. I've learned the hard way that I don't have time, so making the deploy repeatable is much more important to me than making it automatic.

Then there's the fact that makefiles are awful. There's not even enough of a standard syntax to be able to make a good autoformater (or there wasn't when I looked).

I switched to taskfiles and everything about repeatable actions got better.

How to make your online life private

Ivy Puckett — Mon, 29 Sep 2025 04:01:41 +0000

Here's some simple switches I've made to make sure my online life stays between me and the people I talk to.

All of these options are free. No affiliate links, but please support these companies who are making the world a better place.

SMS -> Signal

Signal is awesome because the company which owns it cannot read any of the messages on its own platform.

https://signal.org/

Gmail -> Proton Mail

Same as signal, Proton cannot read any emails they provide.

https://proton.me/mail

ChatGPT -> Lumo

The free tier doesn't give you quite as much, but I haven't had any complaints. Lumo is provided by Proton and has similar security in place.

https://lumo.proton.me/

Gboard -> Futo Keyboard

I hadn't thought about it, but it's kinda creepy that my phone's keyboard used to make network requests. Futo is entirely offline.

https://keyboard.futo.org/

Windows -> Linux

There are so many good distros. I switch often.

Distro personality test: https://distrochooser.de/

Chrome -> Brave

Centered on privacy and built on chromium, I like it better than Chrome.

https://brave.com/

Finally

If you know of anything else that can be done, please let me know.

AI represents nothing new

Ivy Puckett — Sat, 20 Sep 2025 03:11:20 +0000

My dad was a software engineer for 50 years. He once told me, "every ten years the software industry fundamentally shifts. Some people adapt and start making more money, but there's always jobs available for those that don't want to adapt."

In his career, he saw this many times. It's happened to me as well. When I entered the software industry, my company was one of the last to migrate from a data center to the cloud. My role quickly shifted from throwing things over the wall to ops to taking care of ops myself. We still had ops people in our company, but fewer than we would have 10 years prior.

The devops movement, which I see as a collapse of the roles of "dev" and "ops," is mirrored in the more subtle collapse of "dev" and "qa." In my most recent two roles, there are no manual qa people. Instead, I am responsible for the quality of the work I produce and any bugs I release to production.

This is happening to me now

I scorned AI until an engineer I respect (hi Bri!) said that she adopted it and it made her more effective. I gave myself a week where I solely prompted Claude to write code for me. My results were disappointing.

It felt a lot like the tale of John Henry, a railroad stake driver who challenged the machine. After a full day's labor, he beat the machine in driving stakes over the mountain. Exhausted, he collapsed on the ground and the machine kept going.

I write better code than AI. It's more maintainable, better abstractions, better names, and more readable tests. Claude is better at staying engaged and coming back to solve the problem with fresh energy. I used to pride myself on that. Together, Claude and I make a good team because I have shifted from author to reviewer.

I'm currently straddling two high priority initiatives. A week ago my meeting schedule was too full for me to get much done on either. I made progress on both initiatives by prompting an agent to do fine grained, specific tasks in the 5 minutes between meetings. By doing this, I was able to meet deadlines I thought I'd have to push back.

I still write a lot of code. There are some problems it seems AI simply cannot figure out. But my role is different than it was two months ago and I'm more effective because I embrace that fact.

No, AI won't replace you

Higher level languages didn't decrease the number of software jobs available. Neither did OOP, the cloud, CI/CD, or any other scary new concept we've seen over the years. AI won't decrease the number of jobs available either.

How to adapt

Set up a good agent into your current IDE. Claude is a solid choice.
Give yourself a week where every line of code you output comes from a prompt.
Learn from what works and what doesn't.

How to not adapt

It's hard to see the future, but there are a couple of things AI appears to be bad at where you could excel as a dev.

Become an expert in an ecosystem (cloud, programming language, etc.). While it has an approximate knowledge of everything, it is bad at esoteric issues.
Work at a company which can't expose its data for regulatory reasons. Governments, health insurance agencies, etc. may have to rely on good developers that don't want to use AI. This happened with the Cloud and appears to be happening now.
Just wait and refuse to adopt it. This shift has only been going on for a couple years. You have time to adopt it later if you need / want to.

Conclusion

Don't worry about your job. Decide whether you want to adapt and position yourself accordingly.

Introducing: A Go package to reduce err boilerplate

Ivy Puckett — Sun, 14 Sep 2025 01:22:34 +0000

TL;DR look at it here: https://pkg.go.dev/github.com/ivypuckett/to@v1.0.0

Go is a wonderful language, but I keep writing the same three lines of code over and over again:

if err != nil {
    return nil, err
}

Once is fine but if I get unlucky, I may add 15 extra lines of code over the scope of a single method... Just to return errors. Having already implemented this pattern in C#, I knew that it should be possible to eliminate this boilerplate in Go.

The goal

Implement a forward pipe operator / bind monad which enables chaining multiple methods where the input of the next is the output of the last. Upon the first error returned, return that error and the zero value of the expected result. If no errors are returned, return the result of the last operation.

The pain

In C#, the forward piping is fairly easy. I created an extension method on the base object which allows any object to call .Pipe(methodName). That means someone can call 1.Pipe(Increment).Pipe(Increment) and receive 3.

Go is not an object oriented language (thank goodness), but it still has methods. My first thought was to create a struct called Chain with a method .Bind which takes in the next method and returns a new Chain object. It'd be a lot like a linked list. I found out that Go does not support generics on methods. There's no way (I've found) to create a struct with an unbound type.

The next thought was to create a Compose[T, U, V any](func(T)(U, error), fn2(U) (V, error)) func(T) (V, error) function. This kind of function would allow someone to recursively bind functions by calling Bind(fn1, Bind(fn2, fn3)). The syntax was too cumbersome though and there's a small bit of overhead with the number of function calls.

Using variable arguments and type assertions is also promising, but I didn't want to utilize reflection as there's overhead in that as well.

The semi-elegant solution

Ultimately, the interface for this is to.Bind3(input, fn1, fn2, fn3). There is only one extra character and the only overhead is the function call itself. The package provides 1-32 parameter variants.

I considered using bind.Three as it fills a sentence better, but I thought better of it as it may break a programmer's flow easier if we have to think of how to spell a word instead of just typing the new number on a keyboard.

Example

// Before
func SaveWithoutBind(input string) (path, error) {
  sanitized, err := sanitize(input)
  if err != nil {
    return "", err
  }

  cased, err := correctCasing(sanitized)
  if err != nil {
    return "", err
  }

  queried, err := getExtraInfo(cased)
  if err != nil {
    return "", err
  }

  path, err := submit(queried)
  if err != nil {
    return "", err
  }

  return path, nil
}

// After
func SaveWithBind(input string) (path, error) {
  return to.Bind4(input, 
    sanitize, 
    correctCasing, 
    getExtraInfo, 
    submit)
}

Install

go get github.com/ivypuckett/to@v1

How to view productivity

Ivy Puckett — Wed, 21 May 2025 13:56:33 +0000

We maximize what we measure. Without clarity on purpose, we measure the things that make us feel good. These pleasures distract us from deriving joy from what we maximize. In short, we (I) tend to focus on the input more than impact.

By understanding how to define and measure productivity for ourselves, we reset our focus.

First we will define productivity, then we will understand how to use all sources of information, last we'll look at 6 lenses we can use to view our own productivity and how we can "clean the lense" to have a more clear picture.

Defining productivity

If we define productivity as "the ability to have impact," our metrics for whether we are productive are subject to the context in which we operate.

Put another way, there is no consistent metric we can apply to understand whether we are productive.

Furthermore, "productivity" is an attribute. Just like kindness, intelligence or attractiveness, we cannot measure productivity on our own.

Likewise, exclusively allowing others to define our productivity will give us an inaccurate result. Much like looking in a foggy mirror.

Example

I once took on a large-scale, highly-visible project. I collaborated across every team in our org and delivered the first milestone before the deadline.

After I delivered the first piece, the project was cancelled. We had many things in place which no longer served a purpose. Leadership saw the delivery as a win. I saw it as a failure.

From that anecdote, should I say that I was productive because I delivered on time? Productive because leadership saw it as productive? Or should I say that I was unproductive because my time did not end in driving impact?

We must use all available signals to point us towards some sense of true productivity. In this case, two of the three signals I can identify say I was productive. From these signals, I can look for lessons to take forward.

It can be useful to group these signals into internal productivity (ones own view) and external productivity (others view). "Cleaning the lense" of internal productivity is about honestly measuring our impact against an idealized self. For external productivity, it is about empowering those around us to speak to our productivity accurately.

Both are vital to success.

Internal Productivity: Incremental delivery

To understand what we've done and how much we've done, we need to mark it as done.

Said another way, until something is released, it does not speak to our productivity.

Release more often! Break down your work into smaller pieces! When I started doing this, I noticed that I became much more relaxed as a developer. Because I could see how much I'd done, I became more satisfied with how much I was doing. I am also able to push myself to get more done because I tackle a smaller scope at any given time.

Work items can also become too fine grained. The rest of this section is dedicated to understanding what is too large and too small.

A change is too small when it cannot be reviewed without reviewing another change. A change is too large when a comment could block part of the release, but other parts could go out.

I worked with Cory, a good engineer who advocated for 75/75 PRs: 75 lines of code and 75 lines of tests in one pull request. For me, 150/150 is about right. If you're over 300/300, you can probably break things down more.

Kent Beck also gave us one of the best tools for refining this skill in Test Driven Development: By Example. Write a list of things you'll do in the next hour and a list of things you'll do in the next month.

By writing the list of tasks you'll do in the next hour, you're breaking your work into smaller-than-hour-sized-chunks. If deploying one task is not a large enough scope, you can group tasks together into a deployment unit.

This technique is also the easiest way to know your timeline, which we'll talk about soon.

Internal Productivity: Unblock Yourself

At face value, "unblock yourself" is a truism. In practice, when I see someone stuck at a junior-level of productivity it's usually because they don't know when to ask for help or they don't know how to unblock themselves.

Software is a collaborative activity. The only stupid questions are those asked insincerely (yep, there's a story there). The idea of "unblock yourself" is not at odds with asking for help.

When you feel blocked, put in two hours of concerted effort. During the two hour window, continually come back to the question, "ok, but how do I move forward?" If you are tempted to stop pressing forward, imagine that everyone else is on vacation (yep, there's a story there too). If that doesn't help, type out the question you'd want to ask in specific detail and imagine what the person would ask you to try first.

At the end of the two hour window, reach out to someone. If you want to go the extra mile, continue to work on the problem after you've reached out and race to solve the problem before the person responds.

There's no secret here. It's effort. Regardless of outcome, stretching yourself like this strengthens the muscle that leads to productivity.

By attempting to unblock yourself, you're implicitly asking the question, "how would my idealized self solve this problem?" Year over year, you will see a trend of being able to solve larger problems without being blocked.

Internal Productivity: Foreknowledge and experience

This lense speaks to how quickly and accurately you can respond to a given situation. By understanding how large the boundaries of your knowledge are, you can more clearly understand how far you have to go to respond well.

Measure how often you can identify gaps and how well you can expand your borders of knowledge to grow beyond the gap. Every time you find something new and relevant to learn, celebrate.

One day I was brought onto a project. We were integrating with a new downstream system that didn't have an established RPS limit. We wanted to know for sure the system could handle our load.

The week prior I took the time to learn k6. As it turned out, I had the clearest vision for how we could move forward load testing this downstream system. Because I spent time to learn something, I was able to propose a solution. I didn't know I'd be on the project. I didn't know the project would need load testing.

How did I know a load testing tool was the right thing to learn? I listened to the wind (most people call this prayer). That answer probably isn't satisfying though, so here are more concrete steps you can take:

Listen to what others are interested in and ways they've solved problems.
Look around for the holes in how your company does things. Instead of learning a specific technology, evaluate several.
Aim to spend a certain percent of your time learning things. Google calls this 20% time, several people in my community call this Fun Fridays.

Especially the last point is important. If you feel consistently overwhelmed by everything in front of you, slow down. This not only allows you to continue learning, but often gives room to gain perspective. It's a lot like driving, if you only look 5 feet in front of you, everything requires a quick reaction. If you gaze down the road, you'll be able to take your time to react in a more measured manner.

Don't aim for always being "right" about what to learn next. Focus on expanding the boundaries of your knowledge and skill.

For the experience part of foreknowledge and experience, find developers who are better than you and get on projects with them. There's nothing quite as helpful as observing and adopting how others approach problems. If you can't find anybody more senior, find someone more junior. Junior engineers don't have the years of bias you do and there's a lot one can learn from fresh eyes.

External Productivity: Align with Impact

I know a number of developers who don't care about the business side of business; they just want to write code, architect solid systems, and sleep at night without alarms going off. We need people like this on our teams and in our lives.

One common expression I hear from this archetype is that the business doesn't see how productive they are. This is true - the more technical a deliverable, the less likely a business will be able to evaluate its importance.

You must bridge the gap. Define the exact impact of any piece of work you propose. Impact must be related to customer experience, money, or a measured reduction in operational overhead. Unless you find something else the business cares about, ruthlessly de-prioritize anything that doesn't fit into this list.

Once you've gone through this exercise a number of times, you may notice the things that "business people" propose also align with this list almost all of the time. Speaking in terms of impact unifies the two "halves" of the company.

Note: extensibility is intentionally left off the list. If you want to change something for extensibility, include the effort as part of the effort for a business feature. In general, this is a good way to take care of tech debt.

External Productivity: Measure the Unknown

When I was younger, I once estimated that a piece of work would take me 2 months. 6 months later I delivered it. In addition to failing to deliver incrementally, there were unanticipated, external factors preventing me from moving quickly.

Developing skill in estimating, and especially measuring the unknown, is essential to having others reflect back your productivity accurately. Promise to deliver only what you know you can deliver and expose the unknowns that make timelines risky. When you find out your timeline is wrong, expose it as early as possible.

If you're a younger developer being asked for timelines, look for older developers and ask for their opinions. Be aware that, according to The Mythical Man Month, coding is 1/6 of the time it takes to get something to production.

There are a number of circumstances which cause unknowns to creep into the schedule:

When something is unknown because you haven't broken down the work, break down the work.
When it's because the logic is not define yet, the services are unfamiliar or, there's new (to you) algorithms / technologies, estimate with that in mind.

Estimate unknowns first in terms of scale. Will it take hours, days, weeks, months, or years? Then give an "expected" and "if everything goes wrong" estimate.

When you dive into the project and the unknown becomes known, expose early when something will take longer than expected. This develops trust.

By measuring the unknown, we eliminate a common reason it's hard for others to help us evaluate our productivity. Measuring the unknown brings others in to the conversation about how long something will actually take instead of having a binary yes/no for if a deadline will be met. This allows other developers to speak to us for how we are managing our time.

External Productivity: Know your timeline

Know your past. It allows others to reflect back a more accurate representation of your productivity during a performance review.

Know your present. It allows you to accurately reflect back to others what you're currently working on and prioritize new initiatives against current ones.

Know your future. It allows you to not slow down when you finish a project and cast vision to others when it's time to move on from your current initiatives.

Again, as Kent would say, the easiest way to do all three of these is to keep two lists. One list of things you'll do in the next hour and another of things you'll do in the next month. Ticketing systems like Jira most often don't encompass what we do. Take note of things like the conversations you need to schedule and one-off tasks which so often encroach upon our time.

Summary

There's no easy answers. Productivity is ephemeral. Stay present, stay curious, put in the work. Seek to use all sources for a sense of true productivity.

How to write a great one-pager

Ivy Puckett — Sat, 12 Oct 2024 23:01:43 +0000

One-pagers are the fastest mechanism the software industry uses to gain alignment. A one-pager is a document which outlines a problem's context and exposes potential solutions to solve the problem. After a one-pager is made available, it is often presented in a review process to drive toward a decision.

This one-pager outlines the non-obvious rules for writing one-pagers.

1. Assume your audience is 2-3x less informed than you believe.

In doing so, you will surface basic assumptions the group makes. This allows the group to question assumptions before asserting a direction for the review. Many one-pagers are shared beyond the scope the author intended. By writing for a less-informed audience, you help non-technical roles understand why the work needs to be done and what areas of the system are impacted.

2. Adopt egoless writing.

Gerald Weinberg in, The Psychology of Computer Programming, recounts a story where a technical leader wrote twenty lines of code. When another engineer reviewed the code, she found eleven major errors. Instead of the leader defending their choices, they laughed and shared the news with everyone in the office, praising the reviewer for finding so many mistakes.

This is an example of egoless programming. The author celebrated the mistakes pointed out in the code they wrote. When we write one-pagers, we aim to do the same. Every criticism is not a criticism of the author, but of the physical words on the page. Every comment should be treated as an opportunity for celebration.

3. The author owns the document.

A principle I picked up from Amazon: the one who is responsible for writing the document has the authority to determine what the document says. Reviewers find places the document needs to change, but do not decide how to resolve comments. This is most effective when practiced alongside egoless writing.

4. Suggest two alternatives to a course of action.

When only one option is present, reviewers tend to wonder whether the author explored other options and request more research. With two options, reviewers tend to “pick sides” instead of exploring tradeoffs. Three or more options communicates that enough research has been done and it helps reviewers not become attached to any of the options.¹

Mark the first option as recommended. Tell why that option is recommended. Include graphs, risks, and tradeoffs.

5. If someone suggests a nitpick, find a way to accept it.

Anything besides content should be resolved as quickly as possible so as to not detract from the review. Unless it changes the meaning, accept whatever suggestions people have and move on. If it does change the meaning and you can't accept it at face value, message the reviewer and suggest a third way to phrase things. If one person thought the original phrasing was confusing, there are more who haven’t spoken up.

6. Include graphs.

If you don’t include graphs and there’s an opportunity to, someone will request it. Make the graphs beforehand so that you can focus on the content during reviews.

Some people understand the information better after looking at graphs. Consider “graph making” an exercise in accessibility if nothing else.

7. One-pagers are as short as reasonable.

Few one-pagers are actually only one page. However, strive to make them as short as you can. An easy way to do this is to eliminate all tangents beyond the scope of the overview. If you follow the format below, all information should guide reviewers toward making a decision.

8. Follow a format

Format changes per subject, but following this pattern as much as reasonable leads to higher quality reviews. There are a few "tedious" sections (overview, graphs, what the system looks like today), but including these eliminates questions unrelated to the topic.

Overview: One-to-two paragraphs about the area we’re working in, the problem, the services involved, and any other documents or links that are relevant to the discussion.
Current user flow: This may be a section with multiple subheadings depending on the scope of the change. Talk about how data flows through your system. Bring graphs.
Answer questions preemptively: Things like, “what happens if we do nothing?”, “how long do we have to act?”, “is there any off-the-shelf software we could use?”, “what have we tried in the past?”. Make each heading a sentence with the question being answered. That way curious minds can navigate using the document outline.
Proposed changes: as mentioned previously, bring at least three alternatives and mark your recommended path in the heading. Try to use one graph per alternative.

Special thank you to LTK for allowing me to publish this. I originally wrote it as internal documentation and asked whether it would be ok to also publish it here.

This came out of a mentoring session I had with Diana Larsen. In 2020 I asked her how to help my teammates fight for “the right thing” instead of their own perspectives. Her advice was to find a third alternative even if it was a weaker suggestion. ↩

How I got a job at AWS

Ivy Puckett — Tue, 27 Aug 2024 05:01:11 +0000

Background

I had been working at my first software job for 3.5 years and in that time I moved from junior to mid. It was obvious that if I were to keep growing my skills, I would need to move companies.

First thing, I changed my status on LinkedIn to "Open to Work." About three months later, an AWS recruiter reached out to me. Working at AWS was my dream job. She said I could interview for a couple of different teams and we decided I would interview with API Gateway.

I had two months to prepare.

Step 0: Study coding challenges

I read two books and would only recommend Cracking the Coding Interview. This is common advice, but it prepares you well for coding challenges. I read through it, doing at least one problem per chapter and then reviewed as many additional questions per chapter as I had time for.

Step 1: Go to Amazon's interviewing workshop (if available)

AWS provides a number of resources for candidates. They want people to succeed, If I had not attended the hour workshop offered to me by my recruiter, I wouldn't have gotten the job. Most of the advice in this article just echoes their recommendations.

Step 2: Find two stories for each LP

Amazon holds tightly to the Leadership Principles. These are a set of short phrases used to guide decision making.

Choose two stories per Leadership Principle. Each story should:

Follow the STAR technique.
Be short (3-5 minutes max) to explain.
Be tied to a professional experience. If you're fresh out of college, tie it to a collegiate experience or side project.

Write enough of the story down that you'll be able to look at your notes in the interview and remember the story.

This took me around 10 hours. At the time, there were 12 Leadership Principles, which meant 24 stories. I tried my best and came up with around 20 stories with 4 overlapping between principles.

Note: During the interview, I pivoted which stories I told according to the questions asked. Don't be rigid in the interview, but find as many stories as you can and be ready to share any of them.

Step 3: Find useful design patterns and be able to apply them.

The book "Design Patterns" by Erich Gamma is a great resource for this. Don't memorize the entire book (unless you'd like to). Instead, pick 4 diverse patterns that you could see helping you solve problems.

I picked:

Abstract Factory
Builder
Singleton
Decorator
Proxy
Observer
Iterator

I only used one of these as part of the software design portion of the interview. However, I referenced more in passing as the interviews progressed.

Step 4: Look into trees

This is in Cracking the Coding Interview. Please look into it. Even if it's just BFS/DFS.

Step 5: Know O(n) notation

Some people already do but just in case, it's really important. Not just for interviews.

Step 6: Have at least 4 thoughtful questions to ask

Asking questions that show you know what you would like out of a job and want to work with the company can be very helpful. Ask software specific things you care about. One example I like is: "What is your oncall schedule like?" or "What does releasing software look like on your team?"

Figure out what you care about in a job and write down these questions beforehand.

Essential Step: Take too many notes

The picture for this post above is my setup for my interview. This was something that was mentioned in the class - that notes are allowed. Always be up front about your notes. If you're going to reference them and you happen to be remote, mention casually, "hey, do you mind if I reference my notes on this?" Or "let me just scan my notes real quick for a story that matches that."

To be honest, I memorized everything except for the 20 LP stories. But those 20 stories were incredibly useful to have written down and I'm glad I took the time to write more down because it stuck in my brain better.

The interview format

This may have changed since I interviewed, but here are the rounds I had to get though:

Phone screening with a recruiter
Two short, at-home leetcode style tests
Connection with the recruiter for interview timing and training opportunities
4, hour long in-person interviews: system design, software design (patterns), 2 coding exercises. In each, I was asked a behavioral question

Useful Links

Cracking the Coding Interview: https://www.crackingthecodinginterview.com/
Bit Twiddling Hacks: https://graphics.stanford.edu/~seander/bithacks.html
Grokking Algorithms (a very beginner friendly book I learned about recently): https://www.amazon.com/Grokking-Algorithms-illustrated-programmers-curious/dp/1617292230
Design Patterns: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
STAR Interview Technique: https://www.amazon.jobs/en/landing_pages/in-person-interview
Leadership Principles: https://www.amazon.jobs/content/en/our-workplace/leadership-principles

How long did this take?

I didn't have any leetcode experience before I started preparing. My first job didn't contain a coding challenge. I had read the Design Patterns book, but I didn't have a list memorized. This was my first time applying for a FAANG roll.

This was my dream job, so I spent multiple hours most nights studying for it. My guess is that I spent 100 hours preparing for the interviews.

How much of this is luck?

There's always luck involved with interviewing. In my current role at LTK, I was rejected the first time and accepted the second.

What would you have done differently?

I didn't handle the offer stage very well. They ended up offering me 30k more than I asked for because I didn't trust the research I had done on what Amazon typically pays. If I had believed things, I may have been able to negotiate for 10k more in my salary.

When you join, you get to choose which OS you use. I wish I would have asked what OS the people on my team use. There is also an unlisted third option of getting a Linux laptop. I switched to that after 8 months and had a wonderful experience.

What happened after you got the job?

I joined AWS working on API Gateway for 1.5 years. In that time, I was put on an S-Team project where I led various parts of the initiative to great success. I'm being intentionally vague as I'm not sure how much of that I can share.

Then, AWS required everyone to come back to the office. I was asked to choose a location or (by default) move to Colorado. They did it in the best way possible - giving me a year to decide. I'm very grateful for the time frame.

I decided to move on, but working at AWS was one of my favorite professional experiences. The people I worked with were some of the most practiced engineers I've met and when my son grows up enough to where me being at home is not as impactful, I would consider rejoining.

If you want to be an encouraging voice and/or read these posts before they're public, buy me a coffee and let's start a conversation.

How to lose weight as a software engineer

Ivy Puckett — Sat, 20 Jul 2024 18:59:13 +0000

Find out where you are. Take a small step towards your goal. Adjust your understanding based on what you learned. Repeat.

Dave Thomas Agile is Dead, Long Live Agility 2015

Short background

When I was 8, I attended a pool party in my backyard. I had just stepped outside when a small girl looked up at me, ran to her mother, and whispered loudly, "mommy, why doesn't he have to wear a bra?"

In March 2018, I realized I had gained 60 pounds in 4 years. Given the trajectory, I was about to have serious health concerns. I had tried diets and calorie counting apps, even through childhood, and nothing stuck for more than 7 months. I needed something different. I was too disagreeable to hand myself over to a program for an extended period. Really, I needed the wisdom that software engineering provides.

I have successfully lost 60 pounds over a period of 3 years. Then I joined AWS and had a baby. Now I've lost 20 of the 40 I'd gained back.

Principles

When I realized I needed something different, I started to rethink how we do weight loss in America. Most of the marketing centers around adrenaline-induced motivation: do more, keep pushing, just do it. What if these didn't work for me because they don't work?

Instead, I started with a basic premise: approach weight loss as a scientist, not an athlete. Then, run safe experiments on your own body; don't rely on what works for someone else.

Here are the basic principles I've come to align with. By following these, I see sustainable outcomes which have guided me through the past 5 years.

0. Do the least amount of work to achieve your goal.

The muscles one uses for passing a test are unsustainable long term. Until 2018, I made the mistake of "trying too hard." I threw myself into weight loss and burned out quickly.

If you want to succeed, do simple things that use little willpower. I've found that weighing myself once a day and asking, "how did I get here?" then altering one behavior for a day is the least amount of work I can do to achieve a consistent result.

This turns weight loss into a flywheel. Smaller consistent changes lead to big results.

1. Expect to lose weight at the rate you gain it.

Don't sprint. Don't overwork yourself. This is an epic.

I've heard a (probably false) statistic that Americans gain one pound a year. If you lose one pound a year, you're twice as far ahead as most people in America.

If you set reasonable expectations of yourself (3 pounds a month was right for me when I started), you tend to make more sustainable choices. It's more about asking the question, "what does it look like to live comfortably as someone who's 10 pounds lighter than I am?" than "how do I lose weight?"

2. Measure somehow, consistently. Make your tools your friends.

If measuring weight directly sounds like punishment, don't do it. But find a consistent measurement that fluctuates within a fine-grained time window and correlates to the outcome desired.

When you find a measurement, treat it as a friend who tells you the truth, not a competitor. This will encourage engagement with measurement regardless of how the past cycle went.

Don't use calorie counting. This measures the input vs the output. What you're trying to measure is how your body responds over time, not your behavior around food.

3. Run experiments at fine-grained increments.

Shorter than a day if you can. For me, a day is just right. The more data collected, the more you find out how actions impact your outcomes.

This is just utilizing short cycle times.

4. Choose when to gain weight.

When I attend a holiday meal, I gain weight. Don't fight battles unless you're going to win. When you are presented with options, choose consciously whether or not to gain weight. It's not a "cheat day." It's a day where you've chosen your outcomes.

5. Celebrate small things

If you move in a positive direction, say, "yay!" out loud. It helps :)

Hopefully you do this in business too. Celebration is advantageous for so many things.

6. Change your environment more than you change your behavior

Over-utilizing willpower leads to burn out.

Instead of "trying not to grab the ice cream from the freezer," engage with something else that will fill the craving and stop buying ice cream. Maybe it's finding a group of friends to play a table top role-playing game with.

If you tend to eat at places with heavy foods during work, find a restaurant with good food that serves smaller portion sizes. If you tend to go with coworkers, maybe order a hot chocolate instead of a hamburger and then eat at your desk (that's an example from my life).

7. Set reasonable targets in public

It's much easier to lose weight if you're public about where you're at and what you're aiming for. Find a friend group which is happy to have updates on a cadence (maybe join a health challenge) and be open about where you're at.

This is the equivalent of "working in public." However, I don't know where I learned that software principle from and can't find examples. The basic idea is to surface progress early and often, which creates alignment between engineers and stakeholders.

8. Find a reason

For me, there were several. As I've mentioned, there were health implications. There were also several other reasons. Feel free to draw from these and find your own. Your feet take their own steps when you are aligned well.

Here are mine:

Health concerns
Mental health (depression mostly)
An idealized self image
Wanting to interact with future children fully

My experiments as examples

What happens if I use 2% instead of whole milk? I lost 1 pound that day.
What happens if I order a salad at this restaurant instead of a burger? I gained 1 pound instead of 3.
What happens if I go for a run today? Nothing changed.
What happens if I have some whiskey? Nothing changed.
What happens if I shift my food intake earlier? I lost weight. This is one of the most impactful changes I made.
What happens if I cut out caffeine? I gained 2 pounds over two weeks, then I started to lose weight again.

By running these experiments, we start to see what sorts of actions lead to what consequences. Running experiments more than once is also valuable to help isolate and correlate behaviors and outcomes. Once an action is found correlative with a desired outcome, we can utilize those experiments in my everyday life to achieve our goals.

Summary and how to get started.

Handing your body to someone else to take care of doesn't work. We all need to find what works for us. This post really just outlines what we've learned in software: run short experiments and gather data.

Get started:

Choose a measurement tool and cadence for measurement today. Using a scale is effective.
Run an experiment.
Measure and record the results.
Go to step 2.

FAQ

I've talked about this to a couple of people and there are some common questions I get:

"What if I was female assigned at birth?"

If your measurement tool is there to give you information, not to punish you, there's no reason to measure less frequently. Including data about your cycle is valuable information. We're looking for long term progress and fine-grained data collection.

"What if I need to make a change now?"

If your weight has crossed over into having immediate health implications, don't try to move slowly. Move at an unsustainable pace to get to where you need to be, then come back here.

Please follow advice from medical doctors over anything stated here.

New project, who dis?

Ivy Puckett — Wed, 15 May 2024 13:41:52 +0000

There is now a blank public repo for the "fully-featured, infinitely scalable IaaS with predictable pricing." It's pretty minimal, but it's good to slow down and think about how things are laid out. The further I get into this project, the more I question whether a fork-able repository or a CLI that generates boilerplate is the right approach. Either way, it will be valuable to prove that all of these dependencies work together.

Repository: https://github.com/winstonpuckett/sunflower

I've also narrowed what the experience should feel like. A user who has never heard of Sunflower should be able to complete "hello, world" within 5 minutes. This might be hard given the prerequisites (like, "have a Kubernetes cluster already").

Making a free, fully-featured, infinitely scalable IaaS with predictable pricing

Ivy Puckett — Mon, 13 May 2024 12:12:30 +0000

Pretty loud words, but it's what we need right now. Free tiers and usage-based billing make it difficult to visualize how cost will scale over time (search "cloud cost horror stories"). Creating a fully functional architecture based on a cloud provider takes a lot of learning or a lot of resources.

Solutions like pocketbase and coolify come close to solving these problems. However, I wouldn't choose either as I fear architecture lock-in as much as vendor lock-in. Especially in the case of pocketbase, I may be forced to rewrite my application if it were to scale overnight.

Likewise, Kubernetes comes close. It's free, extensible, "infinitely" scalable, and, when cloud hosted, is billed with consistent costs. The only drawback is that you start from scratch. Even if one reduces the needs of the application to the bare essentials, the number of choices and the amount of mental overhead exceeds what a developer should take on.

If Kubernetes had a template or even a list of reasonable defaults to bootstrap a new project, a developer could use this as a baseline, dive into learning Kubernetes at a more reasonable pace, and expand / replace the components without being strongly bound to a particular cloud or scaling strategy.

What should we do about it?

If people show interest, I'd like to pull together tools from across our industry to provide this IaaS to jumpstart independent developers with "best practices by default."

The solution will have:

Auth
NoSQL, SQL, and Key/Value database support
Reverse Proxy & Load Balancing
Static Sites
Backend Services
Frontend Analytics
Backend Metrics
Serverless functions (if requested)
Paging/Alerting
External Configuration
Source Control
Container Registry
Helm Chart Repo
CI/CD Pipelines

This might seem like a lot, and it is, but solutions for everything above already exist. We just need to pull it all together.

How would we do it?

To ensure the platform is cloud agnostic and easily deployable, we start with Kubernetes. Every piece of infrastructure in the platform will be hosted on top of this.

There are a couple of key technologies which satisfy our needs.

NGINX works for static site deployment and ingress and reverse proxy
Gitea provides all CI/CD needs from source control to pipelines
Postgres, and Vallkey satisfy most of our database requirements.
Prometheus satisfies our observability needs.

For a full list of planned integrations, see the diagram above.

Unknowns

What auth solution will be best?
How does this get packaged for both ease and extensibility?
Should serverless functions be included? How much work would that be?
Most projects need to accept a form of payment. What can we do to help people bootstrap that aspect?

Milestones

At every step, everything needs to be scripted and reproducible. Some sort of IaC is required even if it's just a Makefile. Listen and adapt the project to feedback received.

Measure interest by publishing a post and seeing if people respond positively. If they do, move to the next step.
Create a fork-able repository with a single-command deploy script. Running this installs or deletes the platform.
Add Gitea and documentation.
Add auth, a service which connects to it, and documentation.
Add databases, a service which connects to them, and documentation.
Add NGINX, a static site, analytics, and documentation.
Add NGINX as a reverse proxy, a site it exposes, metrics, and documentation.
Add an alert for the metrics, and documentation.
Refactor all IaC to be uniform.

How could one get involved?

Leave a reaction on this post to help me gauge interest. If you want to get involved further, leave a comment with suggestions, ideas, requests, or offers to help.

P.S. This is not in competion with AWS. I wouldn't want to take on hosting any of this.

OpenMP Notes

Ivy Puckett — Sun, 24 Sep 2023 22:27:03 +0000

What is this document?

I recently went through Tim Mattson's Introduction to OpenMP, a 27-video course which outlines all of the major constructs and underlying principles in OpenMP. It's a wonderful course with lots of helpful information and I recommend you take it yourself. Here are my condensed notes on the course.

Why OpenMP?

Parallelism is important because of power usage - Moore's law continues to hold, but the power to runs chip with twice as many capacitors grows almost quadratically with the number of capacitors used.

Instead, by running just two cores in parallel, we find a 40% reduction in the power used for a given input of work.

https://youtu.be/cMWGeJyrc9w?si=XYPQzEBkBwGHgg7_

Concurrency is async (could be happening at the same time). Parallel is when you map so that it is done at the same time.

OpenMP assumes shared address space hardware.

Example of pragmas OpenMP uses:

#pragma omp construct clauses

// simplest
#pragma omp parallel

// You can combine statements like
#pragma omp parallel for
for ...

// Instead of
#pragma omp parallel
{
    #pragma omp for
    for ...
}

Blocks must not exit in the middle.

Shared memory machines

SMP Symmetric MultiProcessor

Operating system treats each thread the same with same amount of time devoted to each thread.

No special blocks of memory - all memory should be equally performant and accessible

NUMA Non-Uniform Memory Architecture

Understands and takes advantage of the fact that access time to certain memory is faster if it's physically closer to the processor .

Nothing is truly an SMP these days, but we pretend it is... at least for CPUs. I'm curious about SMPs vs NUMAs in the world of GPUs.

Random good info

Race conditions and synchronization are the most common errors in parallel programming.
Fundamental model behind OpenMP is the Fork-Join model
A collection of threads is called a Team.
#pragma omp parallel is what forks
omp_set_num_threads(4) tells OMP how many threads to use if it's unspecified in the pragma.
Data allocated outside the parallel block will go on the heap and be visible to all threads. Data allocated inside the block will be allocated to the stack and be visible only to the thread. They use "private" canonically.
A generated function is called a thunk.
Question, OpenMP uses pthreads under the hood when it compiles down. Would an NVIDIA GPU also do that or does it compile to a CUDA-specific implementation?

SPMD - Single Program, Multiple Data
Each thread runs identical code against different data
Cyclic distribution of loop iterations: increment the loop number by the number of threads .
To eliminate race conditions, we can promote a scalar like sum to an array.
Because we may get a different number of threads than we request, you may need to have any thread (id 0 most likely) check the thread count we got.

False sharing:
If independent data happens to sit on the same cache line, each update will cause cache lines to "slosh back and forth" between threads.
Promoting a scalar to an array and using a round-robin strategy is one example where we create false sharing and poor scalability.
One way to avoid false sharing is by padding the array so that separate threads will be guaranteed to show up in separate cache lines. To do this, make the sum array multidimensional and use the first value [i][0] for the actual value
Synchronization solves false sharing without us having to know the underlying cache sizes.

Synchronization
Barrier Synchronization is "each thread should wait until all threads arrive"
Mutual exclusion: "only one thread can access x resource"

Constructs:
Note that pragmas are always applicable to the thing directly below. So use blocks if you want to effect multiple things.

Critical

Only one resource may access at a time:

int sum = 0;
#pragma omp parallel
{
    int id = omp_get_thread_num();
#pragma omp critical
    sum += id;
}

Atomic

#pragma omp atomic

#pragma omp atomic read|write|update|capture

"If the low-level, high performance constructs for mutual exclusion exist on this hardware, use them. Otherwise act like this is a critical section."

Is there any benefit to critical sections in this case? Perhaps critical sections allow for function calls, where atomic only refers to a scalar set operation? Yes - video just said this is just available for simple binary operations to update values.

Barrier

Wait until all threads process to this point before moving on:

#pragma omp parallel
{
    int id = omp_get_thread_num();
#pragma omp barrier
    printf("%d", id);
}

Flush

Compilers are really good at optimizing where reads and writes occur. The order that you place operations in may not be the same order things happen if they are deemed to have equivalent results. This holds true for OpenMP. If you need to make reads and writes consistent, you need to use a Flush.

Creates a synchronization point that says, "you are guaranteed to have a consistent view of memory with the flush set." The flush set is the list of variables inside parenthesis passed to the flush pragma. When you leave off the flush set, everything must be consistent.

All reads and writes before the flush must resolve to memory before and reads or writes to memory after the flush set.

Flushes with overlapping flush sets may not be reordered with respect to each other.

For all intents and purposes, flush is equivalent to a fence in compiler terminology.

Flushes are hard to get right, so OpenMP provides implicit flushes at:

entering/exiting parallel regions
implicit/explicit barriers
entry/exit to critical sections
set/unset of a lock

Flush makes variables available to other threads.

If you spin lock on a variable, you also need to put a flush in the body of the loop. That forces the compiler to read the value every time not from a cache.

#pragma omp flush

#pragma omp flush(variableOne, variableTwo)

Master

#pragma omp master schedules the next block on the main thread. For most use cases of master, you usually want a barrier on the next statement.

Work sharing

Note: there is an implicit barrier at the end of any work sharing construct. nowait skips the barrier. There's no way to turn off the barrier at the end of a parallel region.

Constructs

Loop
- #pragma omp for
- #pragma omp for schedule
  - tells compiler how to split up loops between threads
  - ... schedule(static, optional chunk size): figure out how to break these loops into blocks at compile time
  - ... schedule(dynamic, optional chunk size): create a task queue and pull from it until there's no more work. This is better when you have radically different work from one thread to the next. If you leave off chunk size, it will do one at a time.
  - ... schedule(guided, optional chunk size): start with a large chunk size and get smaller as you go along. This was popular after a paper said this was optimal, but these days we know that the other two are usually better.
  - ... schedule(runtime): take the schedule and chunk size from the OMP_SCHEDULE environment variable or runtime library. This is useful when you aren't sure what schedule you want to use, so you compile the program once and try a bunch of them out. omp_set_schedule() is how you set the schedule.
  - ... schedule(auto): a new schedule which leaves the decision up to the compiler. How is this different from leaving off the schedule parameter? I'm guessing leaving it off means that you accept a default vs do compiler magic.
Reduction
- #pragma omp parallel reduction (operator: variables) | #pragma omp parallel for reduction(operator: variables)
- common task: Find the compute intensive loops, make it so that you can run them independently, insert omp for
- "Loop carry dependencies" Are variables which are dependent on the loops
- accumulating across a data structure is called a reduction.
- when we use the reduction operator, omp creates a local copy of the list of variables and initializes them to the identity of the operator (+=0, *=1)
- when the parallelizations are done, reduction construct combines everything into a single variable for you. Then combines that with the global copy to give you a final answer.
- One interesting thing is that you can do reductions over binary operations like &. Question, does that short circuit?
Section/Sections
- schedule different portions of a sequence on different threads
- sections for the outer block, section for each inner statement
Single
- "only the first three to hit this will execute it."
- note that there's still an implicit barrier because this is a work sharing construct.
- ... omp single
Task
- Consists of data environment, code to execute, "Internal Control Variables" or ICV.
  - In OpenMP there are certain features of the environment that constructs control (like number of threads). These are ICVs.
- #pragma omp task , #pragma omp taskwait
- It looks like taskwait is what creates the implicit barrier in this case. The current thread will keep executing after it has spawned a task with the task construct.
- when you use recursion, look at whether you need to set anything as shared, firstprivate etc. It's so common in tasks that we default private to firstprivate.
Lock
- omp_init_lock() , omp_set_lock() for acquire, omp_unset_lock() for release. omp_destroy_lock() to release the lock's memory. omp_test_lock() to find out if the lock is available, but not wait for it to be available.
- Useful when you have lots of bins where you have a low chance of trying to update two things at the same time.

Runtime Library Routines

omp_get_num_threads() get the current number of threads omp works with.
- outside a parallel region, this returns 1.
omp_set_num_threads() set the current number of threads omp works with.
omp_get_thread_num() get the current thread id.
omp_get_max_threads() get the max number of threads we could use for this system.
omp_in_parallel() is this running in parallel?
omp_set_dynamic() set dynamic mode (whether omp gets smart about how many threads you get for a given parallel region)
omp_get_dynamic() is this running in dynamic mode?
omp_num_procs() how many processors are there on this system?

Environment Variables
OMP_NUM_THREADS the number of threads we request, given this is an integer literal. In a production system, we almost always want to do this rather than have the code be responsible.
OMP_STACKSIZE ask for extra stack size in cases where you allocate large variables to the stack. This prevents stack overflow.
OMP_WAIT_POLICY ACTIVE | PASSIVE if ACTIVE, spin the thread until you get the lock (spin lock). If PASSIVE, suspend the thread until there's available resources. Waking suspended threads costs a lot, so use PASSIVE when you expect to have long wait times and don't want the thread eating resources.
OMP_PROC_BIND TRUE | FALSE if enabled, once you bind a thread to a processor, leave it there. This helps as no processor actually has uniform memory access, so we can optimize for the regions of memory closer to the processor. The disadvantage is that if something else eats up that processor (antivirus scan for example), you don't remap onto a processor which is available.

Data Environment

Heap is shared, stack is local to a thread.

Variables can be shared, private, or firstprivate/lastprivate. First and last means "the xth time you set this, it will remain that."

... for private(tmp) is an example of a declaration.

firstprivate(variable)
lastprivate(variable)

You can declare something as both first and last private. I have questions about what that would do.

Thread private

What if we want a global variable that's private to each thread?

int counter = 0;
#pragma omp threadprivate(counter)

void incrementCounter()
{
    #pragma omp parallel for copyin(counter)
    for (int i = 0; i < 1_000, i++) 
    {
        counter += 1;
    }
}

This isn't a real use case btw, I just wanted an example. For this, we should be using atomic.

Debugging

You need to use a parallel debugger. Visual Studio has one.

Default none for your data environment can help you debug, because it forces you to declare the type of everything.

Remember, the compiler skips pragmas it doesn't recognize are skipped.

Memory Model of OpenMP

There is shared memory and each thread gets a cache. How do you guarantee whether you're getting the most up to date value?

The order you put loads and stores may be quite different than what gets executed.

The memory model gives you precise controls over reads (r), writes (w), and synchronization (s) operations.

Sequential consistency is when r's, w's, s's are in the order you put them in. All threads will see them in this order, and execute as such. This creates a lot of constraints on optimizations.

Relaxed consistency means that you can move, as long as you don't change the output. For instance, you can't change ordering around synchronization operations. You as the programmer have to use these synchronization operations to order what needs to be consistent.

For more on this, see the Flush construct above.

Other Resources

Practical Approach to OpenMP for NVIDIA GPUs by Guray Ozen
Good quote from this course: "Computing is free, all you do is pay for data movement and the computing costs you nothing."
The recapitulation video in this series focussed on the design patterns from the course. It was really good: https://youtu.be/sNmGXNBzofM?si=qzR1cNPh1C02qLM1