Jarek Rudzinski

For years, I've led and mentored diverse teams of software engineers, and one gripe consistently surfaces, irrespective of team makeup or project nuances: "Why do I have to resolve conflicts when cherry-picking commits from the master branch?" 🤔 This complaint hits home. Engineers crave independence to innovate and deliver swiftly, yet software development thrives on collaboration, demanding robust code management and teamwork. 🚀💻 Cherry-picking commits can be an efficient way to incorporate specific changes or bug fixes into a hotfix branch or release candidate, but it often triggers conflicts as changes collide with ongoing developments. This conflict resolution process can be time-consuming, error-prone, and frustrating for engineers, detracting from their productivity and morale. 😫⚔️ The absence of a structured cherry-picking process exacerbates the problem. Here's a simple fix to avoid conflicts: 1️⃣ Track the last merged PR number into the base branch when cutting release/hotfix branches. 2️⃣ When receiving a cherry-pick PR, confirm its base branch PR number. 3️⃣ Ensure all PRs between the last merged and new ones are cherry-picked before merging, preventing conflicts. 4️⃣ Once merged, update the base PR number of the last merged cherry-pick for the next cherry-pick PR review can be verified. Yes, adopting this process entails a bit of change, but the dividends in smoother workflows and happier engineers are well worth it. Let's make life easier for our fellow coders! 💪🛠️ #SoftwareEngineering #CodeReview #Collaboration #ConflictResolution #Teamwork #DeveloperLife #CherryPicking #CodeManagement #ProductivityTips #EngineeringCulture #TechTips #Mentorship #WorkflowOptimization #CodingCommunity

6

One of my favorite acronyms in #SoftwareEngineering is WTF - Where to Focus. When you have a small team you should focus as much energy as possible on the pieces that make your business competitive and buy everything else. I guarantee your cost estimate to justify building a tangential capability over buying it is missing a bunch of hidden cost factors.

4

🌟 Attention Engineering Managers and Technical Leaders! 🌟 In just two weeks, on June 28th at 10 AM PDT, I’m excited to host an interactive roundtable on Feature Flags and Delivery in conjunction with ELC! 🚀 Why Attend? This is a collaborative discussion where your expertise and curiosity are key! Whether you're experienced or eager to learn, your contributions are invaluable. 🔍 Discussion Points: - Decoupling Processes - Boosting Team Efficiency - Optimizing Feature Delivery - Tracking Platform Usage Expect rich conversations on best practices, unique implementations, methodologies, and the latest tools enhancing feature flagging and delivery. Who Should Join? - Engineering Managers - Technical Leads - DevOps Engineers - Software Developers This roundtable is your chance to: - Share your experiences - Gain new insights - Network with peers - Discover practical recommendations RSVP Now and mark your calendars for June 28th at 10 AM PDT! Let’s collaborate and elevate our skills together! #EngineeringManagement #TechLeaders #FeatureFlags #DevOps #SoftwareDevelopment #TeamEfficiency #TechRoundtable

11

Harness founder and CEO Jyoti Bansal caught up with Jennifer Riggins at thenewstack to discuss the problem of developer toil, and how platform engineering can provide a "golden path" to help developers increase productivity and reduce deployment times. Read more here: https://lnkd.in/dHcAwyuc #DeveloperExperience #CEO #SoftwareEngineering #DevOps #PlatformEngineering

1

If you think that the Trump assassination attempt somehow only affects Republicans, know that for some reason Bernie Sanders also cancelled his rally in Portland, ME for this Friday. The problem isn't that there aren't other candidates with better ideas--there are. The problem isn't that people are dumb and don't want a better future for the planet--I think they do. The best candidates are seldom the ones on the ballot. The higher you go in politics this is true: it is often the richest and oldest that are eligible for Presidency, and those with archaic ideas and that support the status quo, and those that serve for self gain. So once again, I'll be voting for the US Presidential candidate, whichever one is on the ballot whose ideas are more progressive. I will vote for the candidate not trying to topple government as we know it, or shake the hands of the Dictators whose hands snuff out the life of dissent. It was a Historic Meeting when Donald Trump shook the hands of Kim Jong Un, because he shook the hand of a despot that murders his own people for consuming the culture of other people, like the 30 teens North Korea recently executed for watching South Korean shows. Similarly, we must express our outrage at China's treatment of the Uyghur population. The Chinese government has detained hundreds of thousands, possibly millions, of Uyghurs in what they call "re-education camps." These camps are nothing short of modern-day concentration camps, where people are held without trial, subjected to political indoctrination, forced labor, and even torture. The world cannot stand idly by as an entire ethnic group is systematically oppressed and their culture erased. I get that some folks think we should just respect their Vote, but look, even Hitler and Putin were elected and that's just shit to think someone would vote for that, yet alone enough to normalize it. So this November, Let's Vote! Let's vote not to become America the Scared and Punished; lets not vote for camps; Lets not roll back the clocks of social progress when the hands of the Science clock will not be turned back by such rhetoric. No, we must work together to accomplish the impossible, if we want a future for our Grandchildren and their children on this planet.

5

Cut Down Your Platform Engineering Org By 50%. Your Business Will Be OK! If you are a large enough tech company, you have a bloated platform engineering team! A couple of decades ago, Joel Spolsky coined the term 'Architectural Astronauts'—engineers who create grandiose, abstract designs that often fail to address real-world problems. Unfortunately, this issue has only worsened, especially in platform engineering. One of my biggest career regrets? Not fighting hard enough against these platform architects. Forced top-down architectures could have been replaced by simple open-source frameworks. I remember it taking over a year to build a self-service API because of a top-down, inversion-of-control framework forced upon all engineering orgs. Read about what killed popular products like Digg, Orkut, NetScape etc.  You can trace it back to bad engineering thought leadership. The amount of platform engineering waste is staggering. Most large tech companies are a graveyard of abandoned platforms and frameworks. Most in-production frameworks have one tenant and are on the deprecation path. The engineering 'thought leaders' who build these systems got promoted and will still rationalize their decisions by passionately talking about edge cases that will never happen. Almost every tech stack begins with off-the-shelf standard frameworks and platforms, mostly open source. But no two businesses are the same. And companies often start building their own platform pieces. As these platform teams grow, they become out of touch with the actual needs of the business. Led by powerful, disconnected engineering leaders, these teams wield more power than they should. Their solution to an inadequate platform? Build a new one, rather than improving the existing one. Unfortunately most of your IP & patents are from these platform teams. Most of your top engineering brain power is working on these platform teams. You will be warned how you will lose the top talent when you question these investments. If you have a 100+ people platform engineering org, cut it down by 50%. Your business will be OK.

30

10 Comments

Everything else being equal, finding bugs statically is better than finding bugs at runtime. Everything else is rarely equal. In the comments to my last post, someone asked about the benefits / adoption of formal verification compared to testing. I have some-but-not-a-ton of experience with formal verification, but I have a lot of experience with static analysis tools. For those of you who don't know, formal verification involves making a mathematical specification for what your code is supposed to do, and then running a tool that can prove it meets that specification. Most people reading this post will now know why most developers don't do it. (It's worth a reminder - tests *are* a specification for your code. They're just one that's written in the language in which you wrote the test instead of being written in math.) It's a truism that it is better to find a bug at compile time than at test time, at test time than at code review time, and at code review time than at deployment time. Each additional step bakes in problematic decisions, giving them the chance to spread to other code, and, eventually, to users. Also, every second that passes between when you write the code and when you notice the problem is a second your brain might use to forget what the code does. I wrote a post a couple of months ago about research done at Google to identify what the ideal static analysis tool looks like. In short: you don't have to do any work to make it run, it never gives you false positives, it points out real problems, and the tool tells you exactly what you need to do to fix the problem. Tools like this are great, and are why Google leans heavily on govet, clang-tidy, and Error Prone (errorprone.info). The more typing that someone has to do to make a static analysis tool work, though, the more that they are likely to write a test, instead (possibly adding a dynamic analysis tool). Formal verification tools are at the far end of this - they tend to make you write specifications for your code, which they then prove the code obeys. Everyone who has worked on a codebase in the broader tech industry knows that most specifications last (at most) as long as it takes to write the code, at which point you realize you got them wrong and change them. This makes formal verification a lot of work for very little reward. The only people who write formal specifications for their code are the ones who are writing code that will kill you if they get it wrong - code to keep airplanes flying or to keep nuclear reactors from meltdown. Most Java development is way back at the other end, where we still beg and plead with people to add nullness annotations (it will help when the jspecify.dev project finishes). This is why sneaking static analysis features into programming languages is so important (I hear you, Kotlin fans). At some point, people's interest in typing annotations drops off, and for everything beyond that, we have tests.

36

10 Comments

The vast majority of content on software engineering I see out there is tailored towards teams that are already high-performing. This makes sense for a few different reasons: high-performers generally write these articles so they write what they know, it's fun and exciting to talk about the latest and greatest, etc. However most teams have a ton of low-hanging fruit that they can address to dramatically improve team performance with low effort lifts. It's very hard to tune an F1 car to go just a bit faster but the simple fact is that most engineering teams are like a commuter car... just by taking a few minutes to put air in the tires you can see dramatic handling and mileage improvements on the daily commute. What are some easier goals to aim for to improve a struggling engineering team? In no particular order: * How big is the average MR/PR? In general a 1,000 line MR/PR isn't four times harder to review than a 250 line MR/PR, it's much much harder. Several thousand line MRs/PRs dropped every few weeks across a team cause lots of issues including merge conflicts and taking a long time to review. After discussing with Product, can tickets be smaller so that merges aren't so big? * How long on average does an MR/PR stay outstanding before getting merged? The older an MR/PR is at merge time the higher the chance of merge conflicts and merge conflicts are a way to generate work but deliver no value to the end user. MRs/PRs that take a long time to merge could be indicative of the team not correctly accounting for the time it takes to review. Should tickets have bigger estimates? * If you're running sprints (and if you're on an underperforming team I recommend switching to sprints ASAP as they bring into focus these types of issues), how often do you have carry-over and how big is it? Improving these estimates is not just an exercise in accounting. A team that estimates work well is one that is not rushed, performant, reviews well, and has time to think about the highest priority tech debt. But most importantly a team that estimates work well is one that delivers on their promises. You may be on a team where these goals have already been achieved or never were an issue in the first place. That's great! But if your engineering team has been underperforming these could be some of the best places to first look. What's some low hanging fruit that you've seen on engineering teams that when addressed had the biggest impact?

11

3 Comments

Want a preview of what I'm going to be talking about in my keynote for RubyConf? You can catch a glimpse of it here!

10

Geoffrey Hinton's contributions is significant enough that I won't quibble with the category for his prize. (Nobel committee could create a special category just for him for all I care.) Widely (and rightfully) recognized as a leading expert in deep learning, his research touches everything from * Foundational concepts such as backprop https://lnkd.in/gMunbBzA * Foundational model architectures such as AlexNet https://lnkd.in/gq2JPJ6h * Optimization algorithms such as Momentum and RMSProp * Visualization techniques such as t-SNE https://lnkd.in/gjuw3vhA I don't think it's possible to overstate how profound the impact of machine learning and artificial intelligence will have on society, promising to unlock discoveries, improving productivity. Even ideas about what mastery of language or reasoning means, will need to be re-thought. Professor Hinton deserves all the credit for all of this.

31

Isn’t it funny that 60% of engineering managers see a shortage of qualified candidates while 56% plan to increase headcount? The math is not mathin’. 🧮 Maybe it’s time to rethink what makes a “good engineer”. Skills are evolving with AI and machine learning, and our criteria needs to evolve too. The “passion engineer” coding all night is rare now, and that’s okay — maybe even better — because we can introduce more diverse skill sets, experiences, and problem-solving. Let’s evaluate our talent definitions, invest in training, and embrace diverse paths of excellence. ✨ For more insights like these, check out Jellyfish's 2024 State of Engineering Management report: https://lnkd.in/eKAJ5jZy

5

I have been recently involved into actively #hiring at multiple software levels and found this insight: Applications that I received for Senior Software position were ~13 times less than the applications I got for Jr. Software Engineer. And Applications that I received for Lead Software positions were ~7 times less than what I got for Senior Software positions What do you think this insight mean? I'll let the audience make out the meaning. #apuravwrites

24

5 Comments

I find interesting the hype about counting downloads for a given tool as a metric for success. I guess it helps to show how popular something is, but I would love it if people also considered other aspects, such as project governance and project activity. Anyway, let's follow the trend (evidence in the comments): - Selenium Java downloads: 98.5M in May 2024 - Selenium active users in the last 30 days: 2.6M. Happy automation!

54

9 Comments

Two facts: First: Jack and the Storefront team handle some of the most interesting problems at Recharge if you're into caching, synchronizing, and lots of data puzzles to solve. Second: I work with the team as Principal so we'd get to have some fun while we do the first part.

17

Every day we hear about AI making rapid advances, and coming up with creative solutions which were unimaginable barely two year ago. My fellow (ex) Planning Comissioner, R "Ray" Wang is moderating a panel on how AI will impact the job market. ============================================== What does AI mean for parents and students in the college and job market? Join our own AI experts from Cupertino for a special community educational event and forum: Liangfang Chao, Ph.D. -Senior Software Engineer -Cupertino City Council Gopal Kumarappan - Head of Engineering at JP Morgan Chase Peter Chu (https://lnkd.in/gM9kQZJQ) - Managing Partner - AsiaTech Ventures Seema Swamy, Ph.D. - Executive Leader of Insights in Fortune 100 Company Moderated by R “Ray” Wang - CEO of Constellation Research - An Expert on AI, Web3, and software - An Author of Best-Selling Books Location: Community Hall, 10350 Torre Ave, Cupertino Time: 6/30, Sunday, 2-4 pm We'll ask questions such as: - Where are we in AI today? - What are the latest AI trends? - How will AI impact future career opportunities? - What should parents know about AI? - How will AI impact students? Must register here -

9

1 Comment

Project update! My application tracking extension is now doing fuzzier matching and injecting new information into LinkedIn (and other sites) to keep me from doubling up on applications. Next up: local storage and bulk import/export operations...

12

2 Comments

I just realized: we should start saying "build memoization" rather than "build caching." We aren't really talking about least-recently-used or time-to-live algorithms, we're talking about "don't bother recompiling this piece if none of its inputs changed." (It has been puzzling me that some people are so deeply fearful of "build cache" as a concept, and honestly I think it's mostly because most build systems have non-hermetic state scattered all over the place. Maybe a slightly more precise term for the type of caching we're concerned with would clarify the semantics in question.)

83

9 Comments

In our recent team retrospective at DNSimple, we recognized a growing concern: technical debt. Many teams face this challenge, but rather than viewing it as a burden, I approach it as a strategic deferred investment in our codebase's design. In my latest blog post, I define technical debt, its impact on software projects, and how we can align its management with our product and engineering roadmap. This post is for developers and non-technical stakeholders who want to understand the nuances of technical debt and how to manage it effectively. Check it out, and let’s continue the conversation on innovating sustainably while managing our technical debt wisely. https://lnkd.in/dcihZ4fE

8