Antonio Giuliana

Developers don’t read your docs the way you think they do. They’re not sitting down with a coffee and reading cover to cover. They’re: → Googling your product + error → Scanning examples → Copy-pasting whatever gets them unblocked fastest And yet so many teams write docs like textbooks. Linear. Dense. Outdated. Here’s the fix: Structure around how developers search. Lead with examples. Surface the top 10 “how do I...” questions and answer them clearly. Your docs should work like a great search result, not a PDF.

73

9 Comments

When did senior engineers start acting like every task needs to be fully scoped for them? Lately, I’ve heard devs say they want “clean Jira tickets.” Let’s be honest about what that really means: No ambiguity. No product thinking. No ownership. Just code. Preferably handed to them in a neat little box. If that’s the kind of work you’re looking for, there are places for it: internal IT at a bank, government contracts, legacy systems in maintenance mode. But if you’re working in a product company—especially a startup or scale-up—that posture won’t get you far. The job is messy. The requirements do change. The customer will contradict themselves. That’s why we need engineers who lean into the ambiguity, not away from it. This is exactly why I wrote Product Driven. Too many teams are optimizing for clean tickets instead of customer outcomes. But product thinking isn’t a “nice to have.” It’s the job. I break down what that looks like and how to lead for it in the book. 👉 https://buff.ly/1W4AoCz

1,750

451 Comments

6 bad software engineering prioritisation methods: Plus 1 experiment for you to try → Decibels: 1. He who shouts loudest (absolute decibels)  2. The squeaky wheel gets the grease (dB x time) Clout: 3. Our Fearless Leader decided 4. HiPPO method (Highest Paid Person's Opinion) Avoidance: 5. Don't care - prioritisation is a product problem 6. Keep most of the people happy, most of the time, AKA keep everyone off your back. Instead, we should be using methods that take into account elements of the following: - Impact (on the company and/or customers) - Effort - Risk / Confidence - Time / Urgency "Prioritisation" suggests that we will work our way down the list until our resources are consumed, i.e. we'll try to do as many things as possible. But we shouldn't.  Many of these things should not even be on the list. Don't waste time with things that don't align with your business goals and business strategies. Try this experiment: For every feature you are asked to build, try to extrapolate what its ultimate value *to your company* will be. You may have to traverse multiple causal relationships, e.g. "If we do this, that will happen. If that happens, it will influence X, which changes Y" etc. If the feature ends up successfully providing that value to your company: - Will you (or anyone) ever know? If not, why not? - Is this value a core focus of the company, currently?

91

48 Comments

Waiting half an hour for your tests to finish? That’s not feedback - that’s punishment 🧪 You might have been there: Every new integration test adds another minute to your overall build time. Twenty minutes turn to thirty. CI times explode. Developers stop writing integration tests and become unhappy. Flaky tests appear. Bugs slip through. Releases slow down. But what if you could slash that time, without deleting a single test? With Spring Test, that's possible. It's a hidden gem called Spring TestContext Context Caching 🏆 So, how do you know how many contexts are spinning up? More importantly, how do you figure out why they aren’t being reused? That’s why I built Spring Test Profiler ⏱️ Meet Spring Test Profiler - the free, open-source x-ray for your test suite. Integration is as simple as this three-step process: 1. Add the dependency (Maven/Gradle snippets appear on screen). 2. Run your tests. 3. Open the report at: target/spring-test-profiler/report.html. Within the report, you’ll see: • How many contexts started, and why. • Which tests are sharing configs versus starting their own. • Exact diffs: profiles, properties, or annotations blocking cache reuse. The overall goal is to help identify cache misses and align your tests to reuse contexts for faster feedback 🚤 Spring Test Profiler: Profile. Optimize. Deliver. Try it yourself: https://lnkd.in/djXVJiNE Below is a demo of a section in the report to analyze and compare two contexts 🆚

49

5 Comments

Engineering managers invest heavily into their teams. But who invests in the engineering managers? 🤷🏻 Every IC I led had a growth plan. We did retros. Talked values. Had biweekly game time (that people actually liked!). But most management teams I’ve been on? Nothing. No team norms. No shared goals. No game time. Most meetings? Just status updates. We preach psychological safety and team cohesion for our reports… But for management teams? We just hope it works out. Managers are just expected to work well together, to be intrinsically motivated, and to be all "raa raa!" for the company. And as for a personal growth plan? Yeah, right...🤣🤣🤣 It's almost as if you since you are a manager, you are expected to just 𝘮𝘢𝘯𝘢𝘨𝘦 𝘺𝘰𝘶𝘳𝘴𝘦𝘭𝘧. And it can be 𝘦𝘹𝘵𝘳𝘦𝘮𝘦𝘭𝘺 lonely and demoralizing. 𝗔𝗻𝘆𝗼𝗻𝗲 𝗲𝗹𝘀𝗲 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝘁𝗵𝗶𝘀? 𝗢𝗿 𝗶𝘀 𝗶𝘁 𝗷𝘂𝘀𝘁 𝗺𝗲? P.S. I’ve never been a manager of managers, so I don’t know what that’s like firsthand. But it does seem like when many people reach that level, some switch goes off and all the things they did to build strong teams of ICs go out the window.

63

35 Comments

𝘞𝘩𝘺 𝘠𝘖𝘜𝘙 Automation 𝘧𝘳𝘢𝘮𝘦𝘸𝘰𝘳𝘬 𝘸𝘪𝘭𝘭 𝘍𝘈𝘐𝘓 𝘪𝘯 6 𝘮𝘰𝘯𝘵𝘩𝘴 (𝘢𝘯𝘥 𝘩𝘰𝘸 𝘵𝘰 𝘧𝘪𝘹 𝘪𝘵) I just audited a $50M company's automation framework. Result? 73% of their tests were failing randomly. Their CTO asked me one question: "How did we go from 10 passing tests to complete chaos?" The Brutal Truth: 85% of Selenium Projects Die the Same Death Month 1: "Our automation is amazing!" Month 6: "Why does everything break when we deploy?" Here's what kills every framework (and the fix): 1️⃣ The "Everything in One Folder" Disaster ❌ Death pattern: UI, API, utils all mixed together ✅ Fix: Dedicated packages → UI, API, POJO, services separated Reality check: Good teams onboard new devs in 2 hours, not 2 weeks. 2️⃣ The "Hardcoded Hell" Problem ❌ Death pattern: URLs, data, timeouts scattered everywhere ✅ Fix: Environment property files + externalized test data Game changer: Switch DEV→QA→PROD with one command. 3️⃣ The "No POJO = No Scale" Trap ❌ Death pattern: Raw JSON strings, manual API payloads ✅ Fix: Request/Response POJOs + schema validation Impact: API tests become 10x more maintainable. 4️⃣ The "Debug Nightmare" Issue ❌ Death pattern: "Test failed" with zero context ✅ Fix: Extent Reports + screenshots + API logs Truth: Debug time drops from 2 hours → 5 minutes The Framework That Actually Scales I've built a production-ready structure that includes: 🏗️ Proper separation of UI/API/POJO layers 🔧 External configurations for all environments 📊 Rich reporting with screenshots & metrics 🚀 CI/CD ready with Docker & Jenkins support 🎯 BDD structure that business teams understand The Bottom Line: Stop building "quick automation scripts." Start building software systems that scale. Your framework should work at test #10 AND test #1000. Want the complete folder structure? 👇 Comment "𝑭𝑹𝑨𝑴𝑬𝑾𝑶𝑹𝑲" and I'll send it to your inbox! Found this helpful? Share with someone struggling with flaky tests! 🚀 -x-x- Full Stack QA & Automation Framework Course with Clearing SDET Coding Rounds: https://lnkd.in/g7tn6Uif #japneetsachdeva

158

10 Comments

'Agile' is ruining developers. While the vast majority of companies completely misunderstand (or don't care and just like buzz words) what agile is and how it works, the idea of iterative development is still hurting young developers. I don't want to argue about how iterating for 3 years before you have a product isn't agile. It objectively is not. What I'm more concerned with is how many young developers are GOOD coders, can debug, can refactor, can solve problems and close tickets. Simultaneously, many of them cannot think past THIS ticket and into what the larger, component/product/system-wide problems may exist. A bug CAN be the whole problem. It can also be a symptom of a problem. I keep encountering devs who are super fast and they fix what they see without understanding the repercussions. I love car analogies, so think of this: You get a flat tire. You get it patched. You get a flat tire. You get it patched. You get a flat tire... At what point do you notice that the crew who put a new roof on your house dropped nails in your driveway? Agile done wrong is robbing young developers of the ability to see the cause of the symptoms because they're rewarded with a dopamine hit when they stop the symptom, even if their 'fix' suppresses the underlying problem and ultimately exacerbates it. That allows bad developers to advance without the skills to actually design, build and architect products and systems. Stop 'doing agile' for a 3 year project with 3 teams of 8. That's just waterfall without adequate architecture and leadership.

182

109 Comments