Ryan Parman

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

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

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

A question to my friends, colleagues, and Linked-In associations that are full TDD developers. Folks who consider themselves proficient or have mastered TDD. 1. How long did it take you to to become very proficient (e.g. to start thinking fully test first)? 2. Did you have a mentor or some aid that helped you along the way? 3. What kept you going down the proficiency/mastery path? I'll start: 1. It took me about 3 years to make it a habit and for me to truly embrace TDD and find that it could replace "test after" development. 2. I did not have a mentor. I did not have YouTube or trainings. I had constraints about creating automated tests. I had teammates that were similarly inclined (constrained). 3. I immediately saw the value of automated tests. I struggled with test first getting in the way of me feeling productive (because I was not proficient and in the learning/gaining proficiency phase) with test first. I'd start every day test first and quickly transition to test after, because it was getting in the way of my "productivity and programming...damn it I just want to write the implementation!" At the end of the day I'd reflect and most days realize that writing tests after was so much slower. Slowly, my time spent test first increased. At some point I transitioned to pseudo coding my intended implementation (to satiate my need to "just write the damn code and not be bothered with tests"). More time passed and I realized that my pseudo code was an inaccurate crutch, I ditched that too and would start with a test. There was a period of time where I'd start with a test and get lost in implementing more than just making the test pass (cycles of sunk cost fallacy here, until I learned it's ok to delete and write it later - faster, better, stronger). There were periods of time where I'd forget to run the test first to see it red before making it green. Too many years messing around with mocking frameworks before learning better design. Struggles with testing internal implementation details instead of external behavior. A whole bunch of stuff I can't think of now and am probably blocking out. I stuck with it though and yikes, does it pay off. I can't imagine not doing TDD now. Coding w/o it is like running through a vat of molasses. So much time wasted in the debugger and writing things that my evil programmer monkey brain distracts me with that YAGNI. I'm writing and asking about this because last week I attended a conference where I talked with a fellow TDDer who'd heard me mention that it took me 3 years to become fully TDD proficient and he shared a similar story even though he was much younger than myself (I attribute my slow adoption due to lack of a mentor/coach and training aids like Pluralsite, YouTube, Jon Reid live coding sessions). I'm curious about others mileage on this. I'll add that I am currently 100% on board with TDD. I am also 100% always on the lookout for a new and better way to replace it. That's off topic though.

45

70 Comments

SignalR is a truly amazing library in the .NET ecosystem and I don't know of any equivalent technologies in other tech stacks. It makes the process of enabling a persistent two-way connection between the client and the server almost effortless. No longer do you have to do low-level WebSocket programming where you need to disassemble each message into a stream of raw bytes and re-assemble it on the other end. SignalR abstracts away all this low-level implementational complexity. In my last week's newsletter, I described how I've built a system where clusters of IoT devices were coordinated by using SignalR. In today's issue, I will show you how to build your first SignalR-enabled application. https://lnkd.in/eJy5x--T

38

9 Comments

i wrote a doc called "llm-for-sre" over a year ago. what was i missing? what's actually working today? --- Can sort of do today: - Generate code - terraform - yaml for k8s (deploy app, create clusters, add healthchecks and limits) - exponential backoff + jitter to http endpoint (go, python, java, js) - Deploy configs - write a canary deployment strategy using any CD tool you want - "now use circleci instead" - Observability - instrument code - create prometheus rules - create SLO and burn rate alerts - General advice - how to set up a multicluster app - what should i do when something breaks? Imaginary wishlist: - Extracting patterns - watch all my logs, find patterns, what should i fix next? - connect to SLOs, alerts - dependency analysis, finding temporal + topological causality - all things "AIOps" etc - Discovering dependencies? - Finding predictive signals? - Look through old postmortems, find themes or common mitigations, recurring patterns. - extract summaries for training - Incident Response - collect my logs during an event - calculate impact  - integrate under a curve for me?   - do SOAP:  - Subjective - SLOs - "it hurts when i do this" - customer impact - Objective - add to context all my yaml etc  - Analyze - think through every model, context - Plan - which generic mitigation should i perform - Systems Control - watch SLO, error rate, take action! - rollback, drain, other generic mitigations - Forecasting - predict traffic, quota, usage, cost Oncall people stuff - handoff analysis, "oncall logbook" ingestion, handoff generation, "situational awareness" assistant - find similar pages/alerts going on across the organization - impact assessment (see: calculate impact above) Next Experiments: - Toil reduction / Automation - transform folder of bash scripts and docs into $other code + scheduler + database? - Architecture: can an LLM read diagrams?  other architecture docs?  can it make suggestions, see gaps?   - Incident analysis: can an LLM read postmortems / incident reports?

74

10 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

Pretty much any piece of software you're building needs some basic fundamental capabilities. These include... - Identity + Authentication + Permissions - Data persistence + Change logs - User Notifications (Notification tray, email, SMS, and more + end-user controls) Can you help me think of more?

9

12 Comments

If Not React, Then What? Frameworkism isn't delivering. The answer isn't a different tool, it's the courage to do engineering. Code that runs on the server can be fully costed. Code that runs on the client, by contrast, is running on The Devil's Computer. As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site's lifetime. Stacks based on React, Angular, and other legacy-oriented, desktop-focused JavaScript frameworks generally take the opposite bet. "Our product stack has bet on React and the various mythologies that the cool kids talk about on React-centric podcasts. You're asking us to rethink the whole thing. Which silver bullet should we adopt instead?" JavaScript remains at least 3x more expensive than equivalent HTML and CSS, byte-for-byte. The choice isn't between JavaScript frameworks, it's whether SPA-oriented tools should be entertained at all. For most sites, the answer is clearly "no". Sites built to inform should almost always be built using semantic HTML with optional progressive enhancement as necessary. Sites that have content that changes more frequently should look to "classic" CMSes or tools like WordPress to generate HTML and CSS. Blogs, marketing sites, company home pages, public information sites, and the like should minimise client-side JavaScript payloads to the greatest extent possible. They should never be built using frameworks that are designed to enable SPA architectures. Managers and tech leads that have become wedded to frameworkism often have to work through a series of easily falsified rationales offered by other Over Reactors in service of their chosen ideology. Note, as you read, that none of these protests put the lived user experience front-and-centre. "...it works for Facebook" To a statistical certainty, you aren't making Facebook. Your problems likely look nothing like Facebook's early 2010s problems, and even if they did, following their lead is a terrible idea. "...React is industry-standard" This is, at best, a comforting fiction. At worst, it's a knowing falsity that serves to omit the variability in React-based stacks because, you see, React isn't one thing. It's more of a lifestyle. Across more than 100 consulting engagements, I've never seen two identical React setups. There's nothing standard about any of this. It's all change, all the time, and anyone who tells you differently is not to be trusted. And if you don't mind me asking, how's that "CSS-in-JS" adventure working out? Still writing class components, or did you have a big forced (and partial) migration that's still creating headaches? https://lnkd.in/efB4PR-A

3

What's the real cost of not involving developers early? ...Yes, involving developers early means more meeting hours. But the cost of NOT involving them? ↔ Constant back-and-forth clarifications ⏳ Rework and delays ⛓ Team disconnection 😑 Frustration ❓ Anything you'd add? Question for you Product Leaders out there: What's the costliest 'hidden' expense you've seen from leaving developers out of early product discussions? Do you agree that we should involve developers early on? What positive examples have you seen from involving developers early in the product process? Thank you so much to Eric Cussen for enriching our recent webinar. #ProductManagement #Agile #Leadership #ProductDevelopment #EngineeringCulture #ProductStrategy

15

I've seen a lot of bugs. (No, not another cicada post). Software here. Egregious, immediately noticeable bugs. The opposite - those that require 6 concurrent conditions and 6 hairs from your nextdoor neighbor and it still only triggers once a month. (Okay, 7 conditions, 6 hairs...don't split those hairs). A continuum of buggage. Those complicated ones, sans the hyperbole - those are your Zero day issues. Regression testing doesn't find them. A super wily code-reviewing look-at-it-all software QA professional (I know the best one)...might...but probably not. How do we even engineer testing all of the complicated conditions? The interrelationships at runtime? I don't see a lot of talk about "how could we have caught this?" in public for disclosed issues. Most of the fixes for Zero days (those security holes best known because they're patched with updates to software like Google Chrome browser, Apple's ioS, Microsoft Windows) are downplayed. You get "Hey, user, look at these new features you're getting, and in whispered voice, "and security updates." Not familiar with the term? Zero day means a security issue without a patch. When the patch arrives, there's a remedy for the problem. Users often don't APPLY the remedy until much later...its own problem...prolonging the risk of the Zero day issue. Back to my kinda silly example. That's a wicked hard problem to test for. A bunch of concurrent situations that then trigger the problem. But, when the problem's a known issue, it's not hard to re-trigger. And therefore exploit. So what do we do? Other than fixing/patching, and communicating? What else is there to add to this conversation? Sunday thoughts. Sunday thoughts.

13

7 Comments

Writing unreadable code does not make you senior

5

2 Comments

"Show me metrics of how much of the monolith codebase has been migrated to our new design system. Break it down by layouts, forms, and other components." Requests like these are not uncommon in tech organizations, but they are not straightforward. With unclear acceptance criteria, likely scope creep, and technical challenges these types of requests are not fun to work in a traditional software development model. Should they even be prioritized? And if so, how do you estimate them? This week I teamed up with another Architect to tackle this exact request. I acted as the Developer utilizing OpenAI’s o1 model, while my partner took on the role of Product Manager. Through iterative experimentation we clarified requirements and refined partial solutions over several days—working in 30-minute bursts between our meeting-packed calendars. By keeping #leanagile principles in mind, I utilized o1 to produce incremental scripted reports and continuously refined the output with feedback. In under 25 interactions with o1, we delivered a solution that provided actionable metrics on migration progress—broken down by component type. This request was the perfect size and shape for today’s state-of-the-art LLMs, a statement I expect not to age well as the AI arms race continues to yield near exponential improvements. Looking ahead, 2025 will be the year organizations need to not only keep up with AI advancements but also learn how to seamlessly integrate LLMs into their workflows.

22

1 Comment

🛠️ Okay y'all, looking for advice: I'm running a handful of small apps for Build Carolina's Development Studio initiative. These are low-utilization apps for relatively small audiences. I'm leaning heavily on Rails at the moment but expect to bring on some JS-stack projects in the near future (likely Next, but I'm always open to the flavor of the week in JavaScript 😅) Here's what I'm finding for hosting: - I still know Heroku best, but I just don't trust them to not enshittify further. 🫠 Every new app here is a liability when Marc decides he needs another island or whatever. 💰 - I'm using a lot of Render and like their devex philosophy, but their pricing is weird (per-service + premium tiers? Pick one!), the big feature gaps in their platform have gone long-unaddressed, and their support has been poor. 🤖 - I'm experimenting with Fly.io: great pricing, but a weird mix of UI-vs-CLI workflows and segmenting project resources is unintuitive. I feel like I'm going to wake up to a huge bill because I accidentally over-provisioned something here. 💸 I'm curious what other folks are doing for small-scale artisanal app hosting in 2024+. Are we all running our own EC2 clusters? Is everyone just writing Next apps for Vercel? Maybe I'm just an old fuddy-duddy looking for a backend host in a static SPA world. 👴 ❓ Tips/tricks/tales welcome. Where are you hosting your lil' bytes right now?

13

39 Comments

Should the entire development team attend all of the sprint events? No, because it’s inefficient and a waste of time. Right? Years ago I battled a tough client who didn't want the developers to attend the Sprint Review. He wanted them to, in his words, “just keep coding”. I argued…how will the team learn about what the customer and the business needs? His predictable answer was “better requirements documentation”. Software engineers are professionals who need to deeply understand the problems to be solve. The intent of sprint events is to provide context for these problems and enable collaboration. Ask your developers if they are receiving value from sprint events. If not, don't exclude them. Fix the events so they enable the development team. #scrum #agile #collaboration

2

Wow, it's time for that big decision again. Should we create the software ourselves or buy it from a provider? This is a frequent concern. Every project, every new feature like adding live collaborative components, needs vetting. You'll likely hit up Google, type in "WebSockets" and start figuring out how you can integrate this into your software. You'll do some homework first, of course. You'll check available open-source software options and contemplate whether to host it yourself. Or, you'll mull over the many vendors out there. Picking and choosing from them based on what they offer can feel daunting. Let's say you want your app to have a chat feature. It's crucial to keep users engrossed and coming back for more. By having a chat feature, your app engagement, and consequently your business, could see growth. So, what to consider when deciding? You could either pick a vendor that can provide such an API or install some open-source software. You'll need to keep maintenance, growth potential, and scalability in mind. Let me use PubNub as an example. Weighing the build versus buy decision? PubNub offers two clear choices. In-house is not always the win-win situation. It drains developer time. Plus, building a solution that a vendor can provide you at a lower price just doesn't make financial sense. You pay less for both the initial cost and following maintenance with PubNub as your vendor. That's why most software is bought from vendors. It's either via an API or as a web portal front end. All are available, from HR to finance to team management. The majority bought is from vendors. Often, the need for extra resources for this kind of project is overlooked. If working in-house, you'll need six developers on a full-time basis for six months. If you have fewer, the timeline to market stretches. The DIY option might lead to a loss of potential revenue and business growth. This lost opportunity cost comes with the in-house terrain. On the other hand, reaching the market quickly increases business growth trajectory. So, decide wisely. #softwaredevelopment #buildvsbuy #businessefficiency

15

4 Comments

The best use case for overseas development I've heard: We have customers in the eastern hemisphere. To support those customers better, we're standing up product, dev, and support teams to help serve those customers needs. Two key ingredients in making that successful: commensurate pay and the same level of performance and accountability as US peers. #software #international #teammanagement #overseasdevelopment #startup #leadership #coaching

6

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

I’m starting to realize that many of the posts I read about using dev processes that don’t involve branching are responding to the use of “Feature Branching,” long-lived (many days or weeks) branches that don’t get merged til a fairly large feature is complete. I realize that it has been a long time since I worked on a team that did that. I’m sure people do, but moving away from feature branches isn't the challenge in many of the recent teams I’ve worked on. The bigger challenges are: - Being able to merge a change to main within an hour or two after it’s done (clunky Pull request processes) - Being able to have something merge (perhaps on a Task Branch) complete in a day as opposed to 2 or 3 (larger tasks or multi-tasking) - Having to support an older release (code is deployed less than once every few weeks). We could get better and reduce all those times. Maybe many teams struggle with Feature Branch workflows, but I’m guessing many are just trying to make their short branch workflow faster and more effective. That’s the audience I’m looking for when I share my Agile Codeline Patterns work. So, while I agree that Feature Branching is evil (as Thierry de Pauw has written), I still see a benefit to using a short branch workflows--

6

72 Comments