Dan Stoner

I've been thinking a lot lately about ways of structuring IaC code, specifically - should this code be separate from application's code, or they can (should) be kept close to each other. When writing backend code, my rule of thumb about managing transactions (and other resources, like connections) is that a method or class cannot interfere with its (transaction's) state if that transaction has been started somewhere outside of that code. In simple words, only a piece of code that started a transaction should make a decision to commit or roll it back. Looks like this model can be applied to codifying infrastructure as well. If an application owns the lifecycle of an infrastructure resource, it is okay to put them in one source code repository. Short unpolished writeup on this topic: https://lnkd.in/emzDC9Nn

2

Recently I was reading about the VW data disclosure, and I was thinking: could an LLM spot this? So I built a small prototype using PDL script, and the results are pretty good to be honest! More detailed information here: https://lnkd.in/dqJSMPkU

5

Why I Broke Up with NavigationView for NavigationStack 💔 Me to NavigationView: "It’s not you, it’s me... Actually, no, it is you. You’re just too... outdated." 😬 💡 NavigationStack slides in: "I heard you like clean, predictable navigation. Let’s make your app drama-free." 🎉 Now, with NavigationStack, navigating between views is so smooth, it feels like I’m swiping on a dating app. No weird reloads, no confusion—just one view at a time. 📱 My app: "Finally, I can stop seeing my views fight each other for attention like it's the Hunger Games." 👀 PSA: If you’re still using NavigationView, it’s like using dial-up internet at a fiber-optic party. Time to upgrade before your code ghosts you! 😂 https://lnkd.in/err3bdJQ #iOSGlowUp #NavigationStackForever #NoMoreViewDrama #SwipeRightOnBetterNavigation

3

I keep hearing the idea that pull requests are bad and that developers shouldn't do them. Well, to me, most of these arguments are somewhat of a straw man variety and they encourage throwing the baby out with the bathwater. Pull requests aren't the problem. Pull requests won't prevent you from doing continuous delivery. The problem is pull requests that take a long time to review and approve. This is the thing that will prevent you from doing continuous delivery. But this is a very avoidable problem. It doesn't have to be this way. In our team, PRs don't normally take long to review and things in the trunk are being updated regularly. So it was in my previous team in my previous place of work. I worked in at least three different teams where we would try to get rid of PRs to see what will happen. In all of those cases, we had to get back to doing PRs because removing them caused more problems that we were trying to solve by removing them. I get it. It may work for some teams that do pair programming all the time, which I see as the only way to keep the code quality up without the PRs. However, this approach will not suit every company and every developer. Many developers I know will find it exhausting having to pair-program all the time. Even when you pair program, PRs still have their use. Just before you push all those commits you created, you can create a PR to view all the challenges to make sure you haven't missed anything. You will not only be able to verify that no temporary code changes go in, but you will also create a nice audit trail of who made the change and who reviewed it. I even sometimes create a PR for my own changes because because it's a tool that makes a pre-push verification very convenient. PRs are just a tool. Just like any other tool, it can either be used or misused. It only causes problems when it's misused and not when it's used properly. This tool may not be useful to you, in which case you may discard it. But you may also find out that it's not as useless as some people say it is and it won't stop you from doing continuous delivery, as these people say.

38

26 Comments

If you're the kind of person who's excited about all the recent S3 feature announcements (bucket policy unlocks via temporary root sessions, up to millions of buckets per account, pagination and region filtering for ListBuckets, conditional writes, ListCallerAccessGrants API) and you're attending re:Invent, then you should come to our storage track session, STG306 Advanced security patterns on Amazon S3. Learn how to use all the exciting new stuff securely in the most interactive format available at re:Invent!

94

2 Comments

There were other examples of this around the web, but none explained _how_ automatic reloading worked in Django. Some implementations felt half-baked. I think this one stands apart. This is also my 70th blog post on DEV 😮 https://lnkd.in/gtC6sBMr

3

2 Comments

A few controversial things I believe about writing code: 1) Code should be comforting, not just functional. I’m not saying it should be flowery or overcomplicated. I’m just saying it should be easy to read and pleasant to navigate. 2) Comments should be personal. Contrary to popular belief, dry comments are a waste of time. “Initializes variable.” “Checks condition.” “Executes loop.” Generic comments are hard to remember and easily overlooked. 3) Humor belongs in your code. “Most people” keep their code dry and formal. Which leads to… Boring code. Disengaged devs. Missed opportunities for connection. Clearly, what “most people” do doesn’t work. So, add a little personality. 4) Consistent formatting isn’t negotiable. 99% of the time, neglecting formatting is a giant mistake. Instead, Robert Martin’s “Clean Code” framework offers a path to elegance without clutter. Consistent naming conventions. Proper indentation. Thoughtful use of whitespace. 5) Pursuing code efficiency at all costs is a silly goal. Because readability and maintainability often matter more. Code that’s easy to understand is a better pursuit in life. It saves time. It reduces errors. It fosters collaboration. If we all have to spend time there anyway, why not make it nice? In a world of deadlines and conflicting requirements, your code can be a refuge, a place of quiet contemplation. 🪷 Read this post and more on my Typeshare Social Blog: https://lnkd.in/gjZbQJrP

8

In other news today, Delta Lake UniForm is now Generally Available. No more data silos, interoperability FTW! UniForm allows you to use a single table format for your lakehouse, getting the top-of-the-line performance and features of Databricks and Delta Lake, but being able to access the data using *any* engine that supports *any* of the common lakehouse formats Delta Lake, Iceberg, or Hudi.

45

A recent significant development in release management I think flew under the radar for many: the Abseil C++ library's adoption of a "live at head" policy as its recommended method of depending on the library. What the maintainers mean by "live at head" is to "depend on and build the latest snapshot of Abseil," which implies that every commit to the head of the repo is to be considered a production release to be compiled in. The head of the main branch is the current release, period. The project is also tagging LTS releases every six months with support of two years pledged but also state there is nothing special about those tags, that it's just a snapshot at that point in time. Despite recommending against depending on their LTS releases, they are providing this for who the live at head policy doesn't work. Abseil release management: https://lnkd.in/egFchD4f --- #ReleaseManagement #Cplusplus #SoftwareEngineering #VersionControl #LiveAtHead #Abseil #OpenSourceSoftware #SoftwareDevelopment #LTSReleases #SoftwareUpdates #embedded #software #Cprogramming #CplusplusProgramming #C

1

Unpopular opinion: It's not the software devs who need convincing. Selling devs on TBD, TDD, CI/CD, and ensemble programming, is a waste of time. We need instead to focus on continuous feedback. We need to sell it to the higher ups. To the people who call the shots. Because in the end, the aim of these tools and processes is to decrease the time it takes for us to collect valuable feedback from customers. Once the c-level people are sold on the merits of fast feedback, software devs will quickly learn how to write and deliver quality code.

6

4 Comments

🏎️💨 Making of a Ridiculously Fast™ API client in R. Why my package is **~17x faster** than the community alternatives that call the **exact same API endpoints**. 👇🏽**design choices matter** ✨ https://lnkd.in/ggi_2XyQ

129

2 Comments

Do you develop trust in your interviews? If you're not in the software profession you probably do. Humans like building trust. Software "professionals" are rather inhuman because they work with keyboards all day. (I'm a software developer but I am a 40 year meditator with a psychology degree so I'm still human.) Can you believe that when devs meet, they quiz each other on trivia? Even worse, they quiz the interviewee on trivia that's already on their resume. How loudly can you scream, "I don't trust you!"??? That changes the entire working relationship! Let me show you via a study... Dan Aerily, the popular MIT and Harvard psychologist who studied lying, was asked to present some of his findings on Madison Avenue (fashion is purely deception about the value of material). After, Aerily asked them for a box of Prada sunglasses for experiments. For years he's been giving subjects tests to learn about deception. He knows about how much people will lie when, say, they're allowed to correct their own answers. In this experiment, Aerily gave two groups of subjects real Prada glasses to wear while they're doing the difficult test. He told them he wanted to see if these glasses would give them a better score. Of course that's not what he was really testing. One group was told that the real Prada glasses were fake. What happens to people when they are put in an untrusting environment? Will they lie more? Yes! the people who thought the glasses were fake lied more than the people who wore the real Prada glasses and knew they were real. Take a step back and you know that it's true. When you see that a person is trustworthy, you treat them with trust. When someone trusts you, you give them trust back. When you know that a person is untrustworthy, you're not going to hand them your trust easily. When someone doesn't trust you, you're not going to be ready to trust them back. Right? If someone hands you a resume and you start quizzing them on minutiae, you're showing them you don't trust the words they wrote. You are asking for the new employee to be an uncooperative slacker. They fooled you by studying for the quiz rather than doing actual work which they know is almost irrelevant to getting the next software job. If they like games like this, watch them play Agile poker. 😂 How did this untrusting environment develop in software but not other professions? I'll let you guess. I can assure you that 30 years ago, before we started quizzing each other, software developers worked much more cooperatively. It was like Gilligan's Island - everyone together working to get off. Nowadays it's like Survivor. Trust goes a long way and if you break the trust when you meet, you might never get it back. #psychology #team #trust #interview

3

2 Comments

Developer downtime: don’t overwork your devs. It’s memorial weekend and I’m lazily sitting on my porch. My kids keep coming in and out of the house, but get stuck because the sliding door keeps coming off the rails and won’t open. Well, since I’ve got nothing else scheduled for the afternoon I investigate the issue. Turns out sliding doors have a bunch of adjustment screws. I adjust them till the door slides smooth. Left in the broken state my kids learned to hit top left side of the door before opening it. Bringing this back to work, I know customer success teams that have a cheat sheet of these maneuvers. Give devs space to observe, we naturally fix these issues.

15

1 Comment

Public Service Announcements to recruiters. If you have the same job post you re-publish every day for many weeks, we notice. This gives hesitation to apply as we have no idea why you rejected the dozens of other candidates that commented "Interested" on your previous posts. Please provide more details about the position so that it's easier for candidates to know if they are a fit or not. If your intent is to build a pool of candidates, please be candid about it and openly say "Need iOS developer to build a pool of candidates". Believe me, they will still apply.

81

8 Comments

SWE Industry: Never manipulate strings in Prod if it can be avoided, and if seen in a PR by a staff/principal engineer would immediately be rejected Job Market: Manipulate these strings in weird ways on this assessment so you can get this job... Wild, if you are interviewing software engineers, give them real world problems to solve, not some arbitrary random string manipulation that we would never do in production. You're likely missing out on a lot of talented people.

31

This is why companies should invest in platform engineering sooner rather than later.

3