🤟🏻 Ryan Magoon

Applitools released a new Playwright SDK recently that makes integration with Playwright even more seamless, utilizing Playwright fixtures for that. It also "supercharged" the standard Playwright HTML reporter, making it integrated with the Applitools dashboard. In the two new videos, I show how to make this integration and core Applitools features, such as match level adjustment and cross-browser testing using Ultra-Fast Grid. Links to the videos are in the comments.

34

3 Comments

Watched a portion of the old Brian Will video on why OOP is bad (https://lnkd.in/epvfRpPR), and bombed out fairly hard when he came out with the puzzling assertion that messages between objects properly speaking shouldn't include object references. Well, there goes your visitor pattern; there goes the UI staple of registering objects with some event bus for callbacks when particular events happen. Is there some source in the literature (Alan Kay, I guess) for this odd restriction? It seems like a basic misapprehension: sure, messages should transfer representations of internal state and not haphazardly leak references to the state itself (otherwise external parties can mutate it without going through the owning object's protocol), but it's also a pretty basic affordance of message-passing systems that the addresses of things that can receive messages are first-class things that can be passed around (compare URIs in REST, or channels in pi calculus). The other odd assertion was that permitting many objects in an arbitrary graph to hold a reference to an object and access its methods was as bad as having global shared state. It fairly obviously isn't: the ability to exercise the protocol for reading or updating a particular bit of state can get passed around to wherever it needs to be, but isn't immediately available to everything, and pretty much the whole point is that you're passing a pointer to the protocol, not the rights to inspect and modify the data structures it guards. It seems that Will wants to argue for a hierarchical flow of messages down a DAG-shaped stack of routines and subroutines with a single controlling root procedure, rather than a potentially cyclic call graph with objects fielding requests from all angles. In practice that's what your average Spring Boot service actually does of course: controller to service to persistence or external client layer, and back up again. But (and this is an argument for a future post) that's because the average Spring Boot service is fundamentally procedural code, with a bit of indirection between modules. Other topologies are possible, and appropriate for particular use cases. The most generous reading I can give of Will's argument is that OOP offers more flexibility than perhaps a majority of actually existing programs really need, and we'd be happier and less burdened by object bureaucracy if we wrote those programs in a more constrained idiom. I actually think that's kind of true, but haven't got to the bottom of what it means in practice just yet.

2

The development cycle https://lnkd.in/ggh5NTfh Posted on October 15, 2024 how to clean up code. run your code to make sure it works while (work_to_do){ make a small change test it commit to git } push to git server on local branch try it on another machine collapse git commits for code review test post for code review How to add a new feature run your code make sure it works while (work_to_do){ write a small test while (test doesn’t pass){ make a small change test it } commit to git } push to git server on local branch try it on another machine collapse git commits for code review test post for code review

2

Check out our latest blog post on Playwright showing you some cool tips and tricks on how to best use --only-changed such as in pre-commit and pre-push hooks. :) https://lnkd.in/dMJ-74Z3

30

Jr. Devs, You need to start thinking outside the box when it comes to your career. I was talking to a friend of mine yesterday and they were telling me about a small business their children (12 and under) had started. I won’t reveal what it is to protect their small advantage. :) But basically, it's providing a simple service that takes very little time for very little cost. It's offering a convenience. Anyway, as he was telling me about it, it was so simple, so obvious, but something I would have never thought of on my own. I’m not really an idea person. I need something to start with, a clear problem to solve. I often need a pre-defined path to follow. Many Jr. Devs need to be less like me, trying to follow the pre-defined path, and more like my friend, looking for things other people might be missing, opportunities no one may notice. Think about ways you could implement what you are learning to help individuals, small businesses, local governments… virtually anyone; to fix a problem, meet a need, or simply make someone’s life easier in areas they may not have thought of themselves. The traditional route into development is clogged right now, so perhaps it’s time to look around and see opportunities from a different perspective. Find a non-traditional route to begin using your skills in a career that might look a little different from everyone else. Who knows, you just might stumble on the next Uber or Airbnb or maybe you just build a great list of clients who need simple work from a trustworthy developer. Take a fresh look at the problem and find a creative solution. #juniordeveloper #mentoring

14

1 Comment

Years ago Brian Pope and I "invented" Mob Design. We'd attended a Mob Programming workshop by Woody Zuill a year or so before and the next project we were on we decided to see if we could also do UI/UX design that way. The way it worked was we had a component library (read: small design system) and we'd go meet with our customer once a week to talk about their needs. They'd tell us specific things they needed their folks to be able to do. We'd ask a million questions to make sure we understood what they were really after. Then we'd return to the office and the whole team (Brian, 2 devs, and me) would grab a giant whiteboard and start talking about what the customer said. Brian would usually start with an initial drawing of what he thought made sense from the UI, but as he talked each of us would grab a marker and start adding or removing things. In under 30 minutes we'd have a design of what that part of the page would look like. And the really cool part was more times than not, by the time we were done talking about it, one of the devs would spin their laptop around and show us how it looked in Storybook. As we talked about this more and more we'd get questions about how it would work on a team bigger than 4 people. At first, we'd say, "I'm sure it'll work." But after talking about it amongst ourselves we realized all that we had invented was collaboration. So, we'd say something like "Yeah, Mob Design is just collaboration and communication, it works on any sized team." Turns out when you're collaborating and communicating a lot of good things happen.

24

5 Comments

NeverRewrite: Anxiety Around Fixing a System You Didn't Create Isaac Askew and Jeffrey delve into the anxiety developers face when dealing with legacy systems they did not create. They explore the reasons behind the fear of fixing legacy systems, the challenges of refactoring, and the skills required to navigate these situations. The discussion emphasizes the importance of understanding legacy code, learning from it, and developing strategies to reduce anxiety when approaching refactoring tasks.

1

Have you worked at a company or on a project where #TDD (Test Driven Development) made a meaningful impact? Let’s spotlight success stories where TDD truly makes a difference. I'd love to hear your experiences, lessons, or even challenges that led to growth. Share your stories in the comments! #SoftwareDevelopment #Programming #Leadership

3

2 Comments

I believe that when people lament about tech debt, it's a misdirected complaint. Engineering teams will always be producing some amount of technical "debt." Even if we write beautiful, well-tested code that fits some noble architectural paradigm and meets every standard we can come up with, it is guaranteed to be deficient in some way--either now or to the team's (or our own personal) future views on what constitutes good code. When we write code, we come to some consensus as a team around what approaches we generally accept and what trade-offs we are generally willing to tolerate. And that's completely normal and unavoidable. But when we complain about tech debt, what we are actually complaining about is a deficient process. All software teams need to have dedicated time to revise our work. Far too often, we prioritize feature development over all other things. The end results of that deficient process are, invariably, twofold: a product with shiny new bells and whistles and a sea of spaghetti under the hood; and a team of stressed out engineers who have to work in a messy, frustrating codebase every single day.

19

11 Comments

"Our documentation is great!" said no one ever. It is always interesting to talk to folks about this problem. It'ss a problem that can be hard to grasp, measure, and even harder to solve. That is; unless you think about it in a different way. A little bit of simplification, structure, and even some AI might do the trick. I also found a new AI tool, Unblocked, while at LambdaConf this week. I am excited to start experimenting with Unblocked and think it could be a game changer when it comes to managing documents across an organization. Check out my latest article where I talk about #knowledgemanagment. Dennis Pilarinos Daniel Horton

28

1 Comment

Don't overlook the 'annoying tasks' that an engineering team becomes accustomed to over time, instead, build a culture where they are solved. “Great DevEx shortens the distance between intention and reality” https://lnkd.in/eZYr9Zbe Don't patch over problems, kill them. In terms of multiplying team velocity, reducing speed bumps caused by bad tooling and process is extremely high impact. As a manager, some problem areas to keep an eye on: * Developers finding it 'hard' to push/pull from any repos needed by the team * Difficulty updating and/or sharing secrets/keys between team members securely * Wasted time going 'back and forth' on merge requests for issues that can be solved by automation (linting, formatting, etc) * Cultural norm of 'ask person X' how to perform a specific task vs. playbooks/documentation - siloing / locked knowledge Any other high impact ones I'm missing?

3

1 Comment

How "you build it, you run it" improves team performance (this article requires an account on leaddev) We talk about 'You build it, you run it', and one of the definitions shared is that from Amazon CTO: “The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings engineers into contact with the day-to-day operation of their software.” It highlights 4 themes: ❥ Ownership and accountability ensure a long shelf life - defining what ownership looks like, the domain, and various contracts is critical to effective ownership ❥ Recruiting new members with a versatile skill set - Lean on hiring T-shaped people, but it also is key to level up the wider team skill set, maximising the breadth of the T when you have specialists ❥ Strong technical foundation streamlines the path to production - engineers have to have the tools, processes, and maturity of platform to be successful with this mindset ❥ Ways of working - teams need to be very clear on key processes (e.g. deployment, on-call) to remove ambiguity as part of the wider ownership of products The article summarises that "You build it, you run it" leads to faster delivery, fewer silos, greater job satisfaction, but I'd also add things like higher quality, better domain ownership, and a more accountable culture. There are no silver bullets, but the more companies adopt this as they go forward, the more effective they can be. https://lnkd.in/ea6JVtqF #DevOps #Lean #Ownership #Accountability #Engineering

15

Last week Claude's Artifacts was just too much fun. Well, hang onto your keyboards! Someone pointed me to a tool that is even more amazing when you know how to use it! I discarded it as a toy first time I saw it but boy was I wrong! Here is my latest video showing what it can do: https://lnkd.in/dfaDTZYA And some examples from it. Be warned, this thing is just too much fun, So proceed with caution. Tool: https://websim.ai/ 3D Physics simulation: https://lnkd.in/dpJqd8Vb Narrated Adventure with Images in collaboration with John Galt: https://lnkd.in/dPgM6bZE websim #Claude #AIWebDev #NoCode #LowCode

1

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

This is a really good article. I highly recommend anyone who's interested in Developer Productivity to read it fully. Developer Productivity is directly related to Developer Experience. Some gems from it... 'Like developer productivity, developer experience cannot be boiled down to a single metric or dimension. By recognizing and measuring DevEx with more than just a single dimension, teams and organizations can better understand how people and teams work, and can then make better decisions. This section presents a framework for determining what to measure, followed by recommendations for how to capture DevEx metrics in your organization." "By focusing on individual factors alone, however, organizations risk losing track of the bigger picture and investing in the wrong areas. It is important, therefore, that organizations also measure the higher-level KPIs for developer experience that serve as North Star metrics for DevEx initiatives. Well-designed KPIs should measure the outcomes that improvements to DevEx correlate with and seek to drive, including productivity, satisfaction, engagement, and retention." https://lnkd.in/dRkfw-Fk

12

3 Comments

Can great design be invisible and beautiful? A backend engineer asked me today what principles I used as a designer. I'm curious if my way of thinking is perhaps controversial among other product designers. This is how I responded: "Great design is an invisible bridge between complex functions and features and a real person on the other end who completes their task and feels successful doing so. Users never think about the UI or the "design," they only see the path to achieve whatever their goal is. It feels effortless." Product design is seemingly full of contradictions. For example, I also firmly believe in the importance of thinking of beauty as a feature and finding ways to incorporate moments of play and joy into our products. How can something be invisible and beautiful? In my mind, the cord that ties these things all together is a deep empathy for the people who use the tools we are building every day.

24

2 Comments