Adal Bueno

Ownership between engineering teams is extremely hard topic. Specifically when teams are owning part of the app / framework / API. And from my experience it always goes through some weird cycle: 1. Component created, everyone starting contributing to it. Obviously, there is no guidelines, generic principles, or even code style. When everyone owns something - that means that no one responsible. 2. Eventually component become critical for business, errors in this component becomes more expensive, time to support it - increasing. Business decided that some team need to own this component. 3. Owning team will start paying tech debt for all these years of mindless committs, refactor something, rewrites. 4. Since guidelines are still not prepared, and component is still kind of messy - owning team does not allow anyone to commit there anymore, or asking tons of changes to merge request. To the point that no one wants to work with that team, or touch that component. Instead of this teams starting creating feature requests. 5. Business can’t be stopped, so owning team starts satisfying those feature requests with paying tech debt in parallel. More teams coming up with feature requests, and owning team starts drawning under never ending requests. They coming up with prioritization frameworks, which always makes someone unhappy because of lower priority of their requests. 6. Finally when team is tired, burned out, and their backlog is way larger than they can consume - someone come up with contribution model - list of guidlines, instructions and requirement on how other team can contribute to the component. Congratulations - now you have a platform team! What will be more optimal way? Create contribution model / guideline generic for the whole company, and apply it every time when more than one team using same component. Save your people :)

58

5 Comments

Value of the good feedback to your reports is extremely important. So, let’s dive into story of engineering manager Bob! You all gonna be familiar with his feelings and situation: https://lnkd.in/gFszHd3s

36

♦ Wrong mindset as a developer: “Why do I need to help unblock others? They should be able to take care of it on their own. I will focus on my own work.” ♦ Right mindset as a developer: “My team is blocked on this particular issue. I read this helpful blog yesterday. I will forward this with a summary. I think it will help a great deal, at the end of the day, we need to ace this project” Great software is always a collaborative effort. The sooner you understand that, the better you will do as a developer. PC Kartikey Sapra

7

Quality must be integrated from the start of the development process, it's an afterthought that Involve QA from the start, plan for edge cases, and build excellence into every step to prevent issues before they arise. #quality #development #productquality

3

2 Comments

I'm currently working with a small group of testers at a company here in the Netherlands to help them take their (and their company's) first steps into test automation. One of the first things I said to them, and one that I find myself repeating every day I work with them, is this one: "You're a software developer now" Why? Even though they're using a low-code tool for their automation efforts, software development is exactly what they're doing. Analyzing requirements. Designing their tests and the scaffolding underneath. Providing instructions to a computer to perform tasks. Testing their work (yes, tests need testing, too). It might not feel to them like they're doing software development, but that's _exactly_ why I keep repeating it to them. Because I want them to feel like that's what they're doing. The impact. The responsibilities. The fact that they're using the exact same tools that the developers at their company use. Are they still testers? Absolutely. But they're developers, now, too.

352

30 Comments

Engineering Managers are drowning in testing candidates—Who’s really failing here? Strangling your engineering team? That’s a death wish. Smart execs don’t play that game. Your product’s begging for attention, and you have customers you need to deliver to. But here you are, jamming the gears with testing candidates instead of focusing on delivering to your customers. Engineers spread thin? They hate the hiring circus. Watching hopefuls bomb tests? That’s just burning daylight. Time, resources, money—you’re torching it all. That’s where we step in. At Savant Recruitment we’re not just pushing resumes. We’re building business'. Our partnerships include: •ScaleHR •Flow, a Deloitte business •Communitech •CoderPad •Wages Corp •Viewpoint.AI + we are working on adding more to be your one stop shop for all your needs to GROW AND THRIVE. We will test your engineers in over 99+ Languages and Frameworks and take this all on my end, so you never have to see a candidate until they pass a technical. This has saved so much time, money, and headaches for execs who are serious about their business and their customers. Although we've been open for 2.5 years, this has been a decade in the making. Test, refine, iterate—again and again. Our gospel? Test till you can’t no more. The old motto is ‘Always Be Selling.’ I say ‘Always Be Testing.’ You can pitch till you’re blue—real power’s in the pivot and drive to do things majorly different and throw away all the old playbooks. We solve real issues that your business' are facing. Why? Because there's no 1 size fits all approach. So for every business problem, we aim to have a solution for it. Your leadership sucks? You come to me Your dev team isn't performing how they should? You come to me Need more incentives in your business? You come to me Can't make decisions? You come to me Want to hire a contractor without the headache of worrying about Payroll? You Come To Me Want to shake up your process and refine it reducing time to fill? You come to me Want to save money, time and headache? You come to me I'm the person you come to, who knows someone, who knows someone, who knows someone, and so forth. If you’re not shaking the status quo, you’re just another face in the crowd. I’m not here to blend in. My take might ruffle feathers. I’m not chasing a popularity contest; I’m chasing deliverables. We’re the ace up your sleeve, building teams that break barriers and doing all the heavy lifting so your Engineering Managers can set it and forget it. I’m after victories with companies that want to get out of this "go for bronze" culture, not validation. So, who's ready to leave "good enough" behind?

98

7 Comments

Managers - do not tolerate cryptic updates from developers. Developer: “The external service sometimes returns code our system cannot handle.” 👉Translation: I need to figure out what is happening and need help. Developer: “Yes, I finished task X. ...... but could not test it because Y.” 👉Translation: I didn’t finish the task, and I’m stuck. Devs can be blocked in different ways, and they do not express it directly. Ask for dates and business/tangible deliverables. It will uncover the actual state of the project. If developers cannot give them to you and still sound cryptic, it is your job to explain what you need. When there is a problem (a blocker), you can help to discuss the details in a smaller group.

17

2 Comments

Do you want to know what is Gorilla Testing? ✅ Monkey Testing - Monkey Testing, also known as random testing, means trying random things to see how your software responds. It's like letting a curious monkey loose on your app to find any hidden issues. 1. No predefined test cases here! Key Features: - Trying random actions - Stress testing - Finding unexpected bugs ✅ Gorilla Testing - Gorilla Testing is all about carefully checking specific parts of your app. It's like having a focused gorilla making sure your critical features are rock solid. - Crafted test cases are meticulously designed to thoroughly test targeted features. Key Features: - Focused testing - Deep dive into important features - Emphasis on quality - Manual testing with human insight Why Use Both? - Combining Monkey Testing and Gorilla Testing in your testing strategy provides the best of both worlds. - Monkey Testing uncovers hidden vulnerabilities, while Gorilla Testing ensures the reliability of your most critical features. - Together, they form a powerhouse duo that elevates the quality of your software and boosts user satisfaction. Credits : Nada Alkatout

4

An easy way to assess a freelance developer's competence is by telling them EXACTLY what you're assessing for. It sounds so simple and obvious, yet many hiring managers (technical and non-technical) fail to do this. Some see interviews more like an interrogation, designed to catch the candidate out, but it's rarely a useful approach. Instead, tell your candidate about your project goals, customer outcomes, and the specifics of how you're assessing them. For example: "We're creating a service that helps users manage their healthcare and medication better. We're building a WebApp that uses A.I. to support user needs. Tell me about any relevant experience you have: - Building WebApps - Building using A.I - Plus, any healthcare experience " Encourage the candidate to first set the scene, and tell you about the project they were working on and what the outcome was. From here, ask them to work backwards, explaining the role they played, what tools and tech they used, and how they collaborated with others. Follow up with simple questions such as: "Tell me how you ensured you understood the brief?" , "How did you validate and test your solution?" , "On reflection, would you have used different tools, or built in a different way". In my opinion, you don't actually need to understand the in-depth technicalities to assess whether someone can help you or not. Since you're being very clear about what you want, all the candidates have an equal opportunity to sell themselves. Simply repeat this process with 3 or 4 candidates and I'll bet you'll know purely by feeling who is still most suitable for your project. After all, the one who can clearly articulate their capabilities is the one who is most likely to understand and deliver against your needs. Hiring freelance developers doesn't need to be complicated. ---------- Adrian G Ward - A technical partner to startups and SMBs. I've hired over 100 and interviewed over 1000 developers, if you need help hiring, give me a shout. #freelancers #developers #hiring #interviews

8

We can't do everything, even if we try. Often software testers wear many hats: they can be project managers, bug finders, automation engineers, and so on. There's an element of domain expertise in many cases as well. But one thing I think most software testers should not be is an "advocate for the customer". Why? Because a lot of the time, software testers simply do not really know what the customer really wants (or does not want). Testers' efforts are better served elsewhere. Check out more thoughts in my latest post. https://lnkd.in/gN_TgFP5

14

5 Comments

Testing Platform Update: We have a test results explorer! Goal Tracker: ▪▪▫▫▫▫▫▫▫▫ 20% of the way to 120 tests in 24hrs We're calling this "Testing Taxi Results". Like you would expect, it's got a list of tests, individual step details, test history and easy to view screenshots. Is there metrics/info I missed? #testing #testautomation

3

1. 𝐠𝐢𝐭 𝐝𝐢𝐟𝐟: Show file differences not yet staged. 2. 𝐠𝐢𝐭 𝐜𝐨𝐦𝐦𝐢𝐭 -𝐚 -𝐦 "𝐜𝐨𝐦𝐦𝐢𝐭 𝐦𝐞𝐬𝐬𝐚𝐠𝐞": Commit all tracked changes with a message. 3. 𝐠𝐢𝐭 𝐜𝐨𝐦𝐦𝐢𝐭 --𝐚𝐦𝐞𝐧𝐝: Modify the last commit. 4. 𝐠𝐢𝐭 𝐬𝐭𝐚𝐭𝐮𝐬: Show the state of your working directory. 5. 𝐠𝐢𝐭 𝐚𝐝𝐝 𝐟𝐢𝐥𝐞_𝐩𝐚𝐭𝐡: Add file(s) to the staging area. 6. 𝐠𝐢𝐭 𝐜𝐡𝐞𝐜𝐤𝐨𝐮𝐭 -𝐛 𝐛𝐫𝐚𝐧𝐜𝐡_𝐧𝐚𝐦𝐞: Create and switch to a new branch. 7. 𝐠𝐢𝐭 𝐜𝐡𝐞𝐜𝐤𝐨𝐮𝐭 𝐛𝐫𝐚𝐧𝐜𝐡_𝐧𝐚𝐦𝐞: Switch to an existing branch. 8. 𝐠𝐢𝐭 𝐜𝐡𝐞𝐜𝐤𝐨𝐮𝐭 <𝐜𝐨𝐦𝐦𝐢𝐭>: Switches the working directory to a specific commit. 9. 𝐠𝐢𝐭 𝐩𝐮𝐬𝐡 𝐨𝐫𝐢𝐠𝐢𝐧 𝐛𝐫𝐚𝐧𝐜𝐡_𝐧𝐚𝐦𝐞: Push a branch to a remote. 10. 𝐠𝐢𝐭 𝐩𝐮𝐥𝐥: Fetch and merge remote changes. 11. 𝐠𝐢𝐭 𝐟𝐞𝐭𝐜𝐡: Fetch changes from the remote repository without merging. 12. 𝐠𝐢𝐭 𝐫𝐞𝐛𝐚𝐬𝐞 -𝐢: Rebase interactively, rewrite commit history. 13. 𝐠𝐢𝐭 𝐫𝐞𝐛𝐚𝐬𝐞 𝐛𝐫𝐚𝐧𝐜𝐡_𝐧𝐚𝐦𝐞: Rebase the current branch onto another branch. 14. 𝐠𝐢𝐭 𝐜𝐥𝐨𝐧𝐞: Create a local copy of a remote repo. 15. 𝐠𝐢𝐭 𝐦𝐞𝐫𝐠𝐞: Merge branches together. 16. 𝐠𝐢𝐭 𝐥𝐨𝐠 --𝐬𝐭𝐚𝐭: Show commit logs with stats. 17. 𝐠𝐢𝐭 𝐬𝐭𝐚𝐬𝐡: Stash changes for later. 18. 𝐠𝐢𝐭 𝐬𝐭𝐚𝐬𝐡 𝐩𝐨𝐩: Apply and remove stashed changes. 19. 𝐠𝐢𝐭 𝐬𝐡𝐨𝐰 𝐜𝐨𝐦𝐦𝐢𝐭_𝐢𝐝: Show details about a commit. 20. 𝐠𝐢𝐭 𝐫𝐞𝐬𝐞𝐭 𝐇𝐄𝐀𝐃~1: Undo the last commit, preserving changes locally. 21. 𝐠𝐢𝐭 𝐛𝐫𝐚𝐧𝐜𝐡 -𝐃 𝐛𝐫𝐚𝐧𝐜𝐡_𝐧𝐚𝐦𝐞: Delete a branch forcefully. 22. 𝐠𝐢𝐭 𝐫𝐞𝐬𝐞𝐭: Undo commits by moving branch reference. 23. 𝐠𝐢𝐭 𝐫𝐞𝐯𝐞𝐫𝐭 𝐜𝐨𝐦𝐦𝐢𝐭_𝐢𝐝: Create a new commit that undoes the changes of a specific commit. 24. 𝐠𝐢𝐭 𝐜𝐡𝐞𝐫𝐫𝐲-𝐩𝐢𝐜𝐤 𝐜𝐨𝐦𝐦𝐢𝐭_𝐢𝐝: Apply changes from a specific commit. 24. 𝐠𝐢𝐭 𝐛𝐫𝐚𝐧𝐜𝐡: Lists branches. 26. 𝐠𝐢𝐭 𝐫𝐞𝐬𝐞𝐭 --𝐬𝐨𝐟𝐭 𝐇𝐄𝐀𝐃^: Undo the last commit, but keep the changes. 27. 𝐠𝐢𝐭 𝐫𝐞𝐬𝐞𝐭 --𝐡𝐚𝐫𝐝: Resets everything to a previous commit, erasing all uncommitted changes. 28: 𝐠𝐢𝐭 𝐛𝐫𝐚𝐧𝐜𝐡 --𝐬𝐞𝐭-𝐮𝐩𝐬𝐭𝐫𝐞𝐚𝐦-𝐭𝐨 𝐫𝐞𝐦𝐨𝐭𝐞_𝐛𝐫𝐚𝐧𝐜𝐡: Sets the upstream branch to the specified

2

Your software product is only as great as your team. And your team is only as strong as their team morale. Here are 5 easy tips on how I boost morale in my team: • Leave positive comments in code reviews • Have 1:1 meetings with your colleagues • Focus on solutions, instead of blaming others • Celebrate small and big wins • Offer help when a colleague struggles Remember, often it's the little things that make the biggest impact.

300

44 Comments

🚨 Scrum Anti-Pattern Alert: Cherry-Picking Tickets! 🍒 As engineers, we love challenging problems—it’s what drives us. But have you noticed a growing tendency in your Scrum team where senior engineers "cherry-pick" the most complex or interesting tickets? This might seem harmless or even efficient, but it’s a major Scrum anti-pattern that undermines team dynamics and growth: 🔍 Why It Happens: Senior engineers gravitate towards what excites them. Teams lack clarity on how to balance skill development and delivery. Pressure to "showcase" expertise. ⚠️ Why It’s Harmful: 1️⃣ Limits Team Growth: Junior members miss the opportunity to stretch their skills and tackle challenging problems. 2️⃣ Creates Dependency: The team becomes overly reliant on a few key players for complex tasks. 3️⃣ Compromises Sprint Goals: When focus shifts to individual preferences, priorities suffer. 4️⃣ Erodes Collaboration: Scrum thrives on shared ownership—this behavior works against that. ✅ What To Do Instead: Encourage Pair Programming: Let senior engineers mentor juniors while solving those challenging tickets together. Create a Fair Rotation: Distribute tickets equitably, ensuring everyone gets a mix of tasks to foster growth and balance. Focus on Sprint Goals: Reinforce alignment with the team’s objectives, not individual interests. Celebrate Diverse Contributions: Recognize all forms of value—be it high-complexity tickets or groundwork. Scrum is about collective success, not individual accolades. Let’s collaborate, share, and grow together—leaving cherry-picking where it belongs: outside the sprint! 💬 What’s your experience with this anti-pattern? How did your team address it? #Scrum #AgileLeadership #TeamGrowth #EngineeringCulture

8

How to (Not) Set Your Software Project up for Success. Success is a question of perspective Yet sometimes I am not sure, what people define a successful software project: • Was it successful, because of the learnings? • Or because of the delivered software? • Or because of the software developers in burn out? Here are 5 steps to failing your project: 1. Build a new product your company has never built before, 2. with a team of people has never worked together before, 3. in a process model they never used before, 4. based on a new technology no one has heard of before, 5. in a programming language, your team has no experience in. Bonus: Do it in a domain with a lot of regulation you have no knowledge in. Why do so many companies think this is the road to success? #SoftwareArchitecture #SoftwareProject #Success #SetupForFailure

1

Day in life of Software Engineer... Story old as time - there's this repetitive, boring and frequently missed thing... Let's automate it! Today’s goal was straightforward: - we use MS Planner for support calendar, - it lacks reminders or synch with Outlook calendars, - people do miss to take action "on their day"... Let's automate it with PowerAutomate workflow template available in MS template library. EASY! However, customising the workflow and polishing the "final bits" took much longer than anticipated. Here's why: 1. Out-of-the-Box Features: PowerAutomate provides an impressive array of features with its existing template library. 🚀 2. Debugging Challenges: Learning the ins and outs of debugging was a painful experience. 3. Documentation Gaps: Topics like casting and formatting aren’t as thoroughly documented as traditional engineering tools. 4. Refactoring Issues: Changing variable names often caused variables to disappear in different places, making refactoring a mess. And there is 🧠 AI Copilot - I tried it... It offered some good options and even built some code for me. But then... - Iterations brought varied answers/solutions, - I could implement and revert changes (that was great - I did revert a lot 😁) - It hinted at functions/options that were decommissioned (old version) 🤯 Eventually, I got it to work. 🏆 What was supposed to be a 30-minute point-and-click task turned into a painful journey of learning the tool for well over 3h. Was it worth it? Yes. Next time, I’ll get the workflow done faster. Did I enjoy it? Kind of - easy to start, hard to polish details. I do prefer more control, but I will try in future and change my mind. Can I recommend it? - For those with stamina to try it and who want to avoid digging through code and just get things done - HELL YES! - You work with MS Stack? YES It has plenty of ready to use templates You can stand on shoulders of giant(s) and use library of solutions ready to run. - If you prefer to stick to engineering principles, build tests, and have more control - I'd stay away. It felt more like a quick and dirty solution, but it did glue things up. 👉 What are your experiences with low-code tools? 🤔 Do you like them? You don't? Or have mixed feelings? Let’s discuss! #LowCode #MSPowerAutomate #Automation #Workflow #SoftwareEngineering #LearningJourney Read this post and more on my Typeshare Social Blog: https://lnkd.in/dRTUub2C

2

Developers often find working in "Sprints" unnatural, unnecessary, and uncomfortable. And despite this (or maybe even because of this) if I was going to do one thing it would be working in Sprints. Speaking as "a Developer" myself. Work doesn't always naturally split itself into neat one or two week chunks. But you know what does? Budget. I don't think it's unreasonable for the organisation to see what they're getting for their money on a regular basis. Not drip fed feature by feature at the team's convenience whenever work is finished but at a high level and on a regular basis so it's clear to the business whether they're getting value for money. And I totally get that Devs often just want to be left alone to "get on with it" but what if "it" is the wrong thing!? I've worked on too many projects where we've built the wrong thing the wrong way because we built what we thought was in the requirements document and didn't have regular check ins, check our understanding and assumptions and get feedback early and often. Sure, you could do that "continuously"... but you won't. But even if you try to, will your stakeholders be available continuously at your convenience!? That's not been my experience. Most business have schedules and cadence (weekly team meetings, monthly management meetings, quarterly budgets) so why not check in with the business at a regular cadence!? And I get that many Developers don't like talking to stakeholders and going to "Sprint Reviews" because they see it as a waste of their time and they'd rather be doing real work and they're worried about negative feedback. But the more we do it the more likely it is that we'll build the right thing and if we're building the right thing and demonstrating progress every couple of weeks those "Reviews" turn into little celebrations and something to look forward to. Speaking as a Developer myself... All of the "reasons" for not doing Sprints are the reasons why I think so many teams and so many organisations would benefit from working in Sprints.

65

48 Comments