Anton Kropp

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

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

Working on a specification for https://lnkd.in/g-pBfAQv. Then I can verify it with tests and https://blprnt.tech/. I'm reminded that wormwood is optimized for readable source code, not UX. There is very little syntax validation.

4

"What's so special about that, I could build it in a weekend!" The dirty secret of most successful web apps is that the actual THING they do is a pretty small part of the codebase. Calculating payroll tax is tricky but not that hard. Turning that into a successful *business* means surrounding that with a TON of stuff that's utterly unrelated to the core business domain, but is absolutely necessary to support users, provide business info, make billing work, etc etc. #SaaS

32

7 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

For 10+ years I have been building software and this article really clarified something I’ve always felt about the architecting process. Many software engineers focus too much on the HOW and not the WHAT. When architecting software, we should put more energy towards understanding the problem we are solving and the customers' needs. Think about building a house. Do customers really care about plumbing layout, electrical wiring, foundations, and joist sizing? Or, do they care about something more abstract like having a kitchen large enough to host a big family gathering? Once you clearly understand the needs of your customers, implementation details become more obvious.

11

Join me for an interesting session on #devex and how to think about organizational and engineering metrics.

13

Woah there, "hiring juniors is about making your entire team better" is exactly the kind of unhelpful, oversimplified headline that needs an A4 sheet of caveats adding. Juniors are a massive investment and the suggestion that simply hiring them will make the team stronger is not right at all. Processes that support the career development of more junior engineers aren't accidental byproducts, they're deliberate. Senior engineers need to be provided the time, headspace, training and support to coach, mentor and develop their more junior colleagues. You know what doesn't work? Hiring juniors into overstretched/under-resourced teams where the seniors are overcommitted and under pressure to meet aggressive deadlines. And I've seen this more times than I care to mention. In the scenario where you've got small teams that are under pressure, and the existing engineers don't have time or headspace to coach someone junior, you are *always* better hiring another senior. Someone who reaches autonomy faster will always be better in that situation. If you hire a junior into that team you won't get better code reviews, more innovation or a richer culture of learning. You'll end up with an under-developed junior who struggles to progress their career, and some seniors who feel like they're doing the junior a disservice by being unable to support them properly. It's horrible. And I've been there. Were we all juniors once? Yep. Should *every* team hire juniors? Absolutely not.

4

You’ve probably read articles and linked-in posts stating that onboarding and growing Associate (beginner) engineers _does not work_ in the remote world. They'll tell you that new staff NEED to be in the office. End of. Having worked in engineering for many years, I’ve seen folks grow in both in-office, on client sites and in remote-first teams. I’ve seen beginner engineers thrive in a remote world, and I’ve seen them fail in-office. So I could both understand the issue, and also see how wrong it was. I've come to think that is not about their situation. It's about the plan: how we interact, orient, inspire and support them. In short. If we don’t place them on stable ground and help build strong foundations: they will fail, no matter how the people prefer to work. When I heard Pleo was hiring new sets of Associate Engineers, of course, I knew I had to get a little involved. I was passionate that we could, and should, get this bang-tidy and set up to build super new engineers. What amazed me was the energy and commitment from the rest of the org. I made a few suggestions on how we might orient our new folks best to join their Pleo engineering teams, and we invited in a whole pile of Pleo engineers to help make it happen. They were amazing. They delivered a brand new set of hands on introductions and workshops - focused on the skills our new engineers would need to thrive in their teams. We worked to cover the most important skills needed so they could drop into a team and begin delivering. Did we get it right? Time will tell, but I’m confident this cohort know how Pleo engineers better than I did when I arrived, and you know what, we are doing it all over again in a few more months. What to know the deets on our syllabus? Shout up in the comments.

39

8 Comments

Tailwind is an awesome utility-first CSS framework. I've found myself really enjoying it but have also identified some potential challenges when creating larger components, especially within a design system that includes multiple variants of a single component. So I thought I'd share an interesting approach to these challenges! #tailwindcss #web #development #frontend #reactjs #CSS #javascript

7

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

The open source team I'm a volunteer for at Couchers.org is looking for (volunteer) UI/UX Designers. Come join us, we're fun! Our Figma designs can't keep up with our engineers...halp? Maybe you're taking a sabbatical and want something on your resume for that time. Maybe you wanna see what it's like to work on a project that has nothing to do with stakeholders or investors, where we just do stuff our users want and we think is cool. Maybe you're passionate about traveling and old school couchsurfing vibes and wanna nerd out about it on a team with other travelers. Or maybe you just love designing stuff and are looking for some public portfolio pieces? Join our volunteer team! More info here: https://lnkd.in/g_PwevB9 On a side note, if you're a software engineer with some experience in Javascript or Python and looking for a fun project, we're always looking for more people too. (Please I need more people to review my PRs lol). #uxdesign #uxui #figma #design #opensource #volunteer

11

Mastering Shadow DOM interactions? Discover how Playwright simplifies automating nested elements and unblocks the secrets of Shadow DOM testing, ensuring precise targeting and reducing test flakiness effortlessly with advanced superpowers.  Explore our blog on leveraging Playwright for effective web testing with Shadow DOM at Nagarro! Stay tuned for more in this series from Bharat Garg and myself, on using Playwright to solve intricate challenges. Sincere thanks to Khimanand Upreti, Vineet Bhatt, Alok Sharma, Debaghna Mukherjee, for giving invaluable feedback in refining the content. #WebTesting #Playwright #ShadowDOM. https://lnkd.in/gSwar-bV

38

11 Comments

"The primary goal should be 'our developers write tests for any code that goes into production.' Anything less than that is an opportunity for those folks with a little less discipline or more anxiety about delivery times to backslide and abandon the primary goal of having tests for all your code. There are two major forces that lead applications towards not having any tests:  * The first is that it's hard to teach beginners in a language how to use testing tools; they are still just learning the language itself! * The second force is the work-culture pressure that says you don't have time to write tests." - Chris Hartjes #tdd #testdrivendevelopment #testing

4

Great article by Ray Carnes. In my 20+ years in the software industry I've seen companies learn and relearn the basics again and again because each generation of leaders think things are "different this time" because of such and such technology. The frameworks, platforms, underlying technology changes but the principles and foundations are still the same. #softwareengineering

20

3 Comments

There are two types of mid-level software developers out there: First: Those teaching and sharing how to handle thousands or millions of transactions per second (100K tps). Second: Those avidly watching and reading about how to handle thousands or millions of transactions per second. Meanwhile, both are working on systems that barely handle 10 transactions per second on a good day. #ScalableSystem

13

1 Comment

I think many people in the software industry make the mistake of viewing tech debt like a loan in deferral. They decide to add to their debt assuming there is no short term cost, but one day they will have to start paying it down (or declare bankruptcy with a huge rewrite). A more accurate analogy would compare your tech debt to credit card debt. You immediately start paying for this debt. The minimum payment would barely chip away at the interest accruing. You pay that cost in your project with every feature. The tech debt you add today makes the feature you add tomorrow more difficult. Every work item you take on without addressing the debt will be more difficult, and will likely add to the debt itself. With both analogies, a common end result is crippling debt that grinds your progress to a halt. However, the former analogy assumes that you are making quick progress, when that simply isn't the case. "The only way to go fast, is to go well." - Robert C. Martin

14

Is this valid TypeScript? Why or why not? I 💖 type safety. I recently gave an engineering talk on it at Stay AI and this line of code helps explains the differences between values and types in TypeScript quite succinctly.

6