Culture and Methodologies Resources

DZone's Featured Culture and Methodologies Resources

Want to Become a Senior Software Engineer? Do These Things

By Seun Matt

CORE

In my experience working with and leading software engineers, I have seen mid-level Engineers produce outcomes worthy of a Senior, and seniors who are only so in title. High-performing mid-levels eventually overtook under-performing seniors. How you become a Senior Software Engineer is important. If you become a Senior because you're the last man standing or the one with the longest tenure. I am afraid that future upward movement may be challenging. Especially, if you decide to go elsewhere. I have been fortunate to directly mentor a couple of engineers to become Senior, and witness the journey of others. In this article, I am going to discuss the day-to-day activities that distinguish the best and how you can join their ranks. Know the Basics Bruce Lee famously said: "I fear not the man who has practised 10,000 kicks once, but I fear the man who has practised one kick 10,000 times." This is a homage to the importance of getting the basics right. 1. Write Clean Code If you want to become a Senior Software Engineer, you have to write clean and reliable code. The pull request you authored should not be like a Twitter thread due to the myriad of corrections. Your code contributions should **completely** address the assigned task. If the task is to create a function that sums two digits. In addition to the `+` operation, add validations. Take care of null cases, and use the correct data type in the function parameters. Think about number overflow and other cases. This is what it means to have your code contribution address the task at hand completely. Pay attention to the coding standard and ensure your code changes adhere to it. When you create pull requests that do not require too many corrections, work as expected, and more, you'll be able to complete more tasks per sprint and become one of the top contributors on the team. You see where this is going already. You should pay attention to the smallest details in your code. Perform null checks, and use the appropriate data types and more. For example, in Java, do not use Integer everywhere just because you can; it takes more memory and may impair the performance of your application in production. Instead of writing multiple, nested if...else constructs, use early return. Don't do this: Java public boolean sendEmailToUser(User user) { if(user != null && !user.getEmail().isEmpty()) { String template = "src/path/to/email/template"; template = template .replace("username", user.getFirstName() + " " + user.getLastName()) .replace("link", "https://password-reset.example.com"); emailService.sendEmail(template); return true; } return false; } Do this instead. It's cleaner and more readable: Java public boolean sendEmailToUser(User user) { if(user == null || user.getEmail().isEmpty()) { return false; } String template = "src/path/to/email/template"; template = template .replace("username", user.getFirstName() + " " + user.getLastName()) .replace("link", "https://password-reset.example.com"); emailService.sendEmail(template); return true; } Ensure you handle different scenarios in your logic. If you are making external HTTP calls, ensure there's exception handling that caters to 5XX and 4XX. Validate that the return payload has the expected data points. Implement retry logic where applicable. Write the simplest and most performant version of your logic. Needlessly fanciful and complicated code only impressed one person: your current self. Your future self will wonder what on earth you had to drink the day you wrote that code. Say less about how other people will perceive it down the line. What typically happens to such complicated code, which is not maintainable, is that it gets rewritten and deprecated. So, if your goal is to leave a legacy behind, needlessly complicated, non-performant, hard-to-maintain code will not help. If you're using reactive Java programming, please do not write deeply nested code - the callback hell of JavaScript. Use functional programming to separate the different aspects and have a single clean pipeline. 2. Write Readable Code In addition to writing clean code, your code should be readable. Don't write code as if you're a minifier of some sort. Use white-space properly. Coding is akin to creating art. Write beautiful code that others want to read. Use the right variable names. var a = 1 + 2; might make sense now, until you need to troubleshoot and then begin to wonder what on earth is a. Now, you have to run the application in debug mode and observe the values to decode what it means. This extra step (read extra minutes or hours) could have been avoided from the outset. Write meaningful comments and Javadoc. Please don't do this and call it a Javadoc: Java /** * @author smatt */ We will be able to tell you're the author of the code when we do Git Blame. Therefore, kindly stop adding a Javadoc to a method or class just to put your name there. You're contributing to the company's codebase and not an open-source repo on GitHub. Moreover, if your contribution is substantial enough, we will definitely remember you wrote it. Writing meaningful comments and Javadoc is all the more necessary when you're writing special business logic. Your comment or Javadoc can be the saving grace for your future self or colleague when that business logic needs to be improved. I once spent about 2 weeks trying to understand the logic for generating "identifiers". It wasn't funny. Brilliant logic, but it took me weeks to appreciate it. A well-written Javadoc and documentation could have saved me some hours. Avoid spelling mistakes in variable names, comments, function names, etc. Unless your codebase is not in English, please use comprehensible English variable names. We should not need Alan Turing to infer the function of a variable, a method, or a class from its name. Think about it, this is why the Java ecosystem seems to have long method names. We would rather have long names with explicit meaning than require a codex to translate one. Deepen Your Knowledge Software engineering is a scientific and knowledge-based profession. What you know counts a lot towards your growth. What you know how to do is the currency of the trade. If you want to become a Senior Software Engineer, you need to know how to use the tools and platforms employed in your organization. I have interviewed great candidates who did not get the maximum available offer because they only knew as far as committing to the production branch. When it comes to how the deployment pipeline works, how the logs, alerts, and other observability component works, they don't know; "The DevOps team handles that one." As a Senior Software Engineer, you need to be able to follow your code everywhere from the product requirement, technical specification, slicing, refinement, writing, code reviews, deployment, monitoring, and support. This is when you establish your knowledge and become a "Senior". Your organization uses Kibana or Grafana for log visualization, New Relic, Datadog, etc. Do you know how to filter for all the logs for a single service? Do you know how to view the logs for a single HTTP request? Let's say you have an APM platform, such as Datadog, New Relic, or Grafana. Do you know how to set up alerts? Can you interpret an alert, or do you believe your work is limited to writing code and merging to master? While every other thing should be handled by "other people." If you want to become a Senior Software Engineer, you have to learn how these things are set up, how they work, be able to fix them if they break, and improve them too. Currently, you're not a Senior Software Engineer, but have you ever wondered what your "Senior Engineer" or "Tech Lead" had to do before assigning a task to you? There are important steps that happen before and after the writing of the code. It is expected that a Senior Software Engineer should know them and be able to do them well. If your company writes technical specifications, observe refinement sessions, poker planning, or ticket slicing. Don't be satisfied just being in attendance. Attach yourself to someone who's already leading these and ask to help them out. When given the opportunity, pour your heart into it. Get feedback, and you become better over time. If you want to become a Senior Software Engineer, be the embodiment of your organization's coding standard. If there's none — jackpot! Research and implement one. In this process, you'll move from someone who ONLY executes to someone who's involved in the execution planning and thus ready for more responsibility, a.k.a. the Senior Software Engineer role. Still on deepening your knowledge, you should know how the application in your custody works. One rule of thumb I have for myself is this: "Seun, if you leave this place today and someone asks you to come and build similar things, will you be able to do it?". It's a simple concept but powerful. If your team has special implementations and logic somewhere that's hard to understand, make it your job to understand them. Be the guy who knows the hard stuff. There's a special authentication mechanism, and you're the one who knows all about it. There's a special user flow that gets confusing, be the one who knows about it off-hand. Be the guy in Engineering who knows how the CI/CD pipeline works and is able to fix issues. Ask yourself this: Do you know how your organization's deployment pipeline works, or do you just write your code and pass it on to someone else to deploy? Without deepening your knowledge, you will not be equipped to take on more responsibilities, help during the time of an incident, or proffer solutions to major pain points. Be the resident expert, and you can be guaranteed that your ascension will be swift. Be Proactive and Responsible I have once interviewed someone who seems to have a good grasp of the basics and the coding aspect. However, we were able to infer from their submissions that they've never led any project before. While they may be a good executor, they're not yet ready for the Senior role. Volunteer and actively seek opportunities to lead initiatives and do hard things in your organization. Your team is about to start a new project or build a new feature? Volunteer to be the technical owner. When you are given the opportunity, give it your best. Write the best technical specification there is, and review pull requests from other people in time. Submit the most code contributions, organize and carry out water-tight user acceptance tests. When the feature/project is in production, follow up with it to ensure it is doing exactly what it is supposed to do and delivering value for the business. Do these, and now you have things to reference when your name comes up for a promotion. Furthermore, take responsibility for team and organizational challenges. For example, no one wants to update a certain codebase because the test cases are flaky and boring. Be the guy who fixes that without being asked. Of course, solving a problem of that magnitude shows you as a dependable team member who is hungry for more. Another example, your CI/CD pipeline takes 60 minutes to run. Why not be the person who takes some time out to optimize it? If you get it from 60 minutes to 45 minutes, that's a 25% improvement in the pipeline. If we compute the number of times the job has to run per day, and multiply that by 5 days a week. We are looking at saving 375 minutes of man-hours per day. Holy karamba! That's on a single initiative. Now, that's a Senior-worthy outcome. I'm sure, if you look at your Engineering organization, there are countless issues to fix and things to improve. You just need to do them. Another practical thing you can do to demonstrate proactivity and responsibility is simply being available. You most likely have heard something about "the available becomes the desire." There's an ongoing production incident and a bridge call. Join the call. Try to contribute as much as possible to help solve the problem. Attend the post-incident review calls and contribute. You see, by joining these calls, you'll see and learn how the current Seniors troubleshoot issues. You'll see how they use the tools and you'll learn a thing or two. It may not be a production incident, it may be a customer support ticket, or an alert on Slack about something going wrong. Don't just "look and pass" or suddenly go offline. Show some care, attempt to fix it, and you can only get better at it. The best thing about getting better at it is that you become a critical asset to the company. While it is true that anyone is expendable, provided the company is ready to bear the cost. I have also been in a salary review session where some people get a little bit more than others, on the same level, because they're considered a "critical asset." It's a thing, and either you know it or not, it applies. Be proactive (do things without being told to do so) and be responsible (take ownership), and see yourself grow beyond your imagination. Be a Great Communicator Being a great communicator is crucial to your career progression to the Senior Software Engineer role. The reason is that you work with other human beings, and they are not mind readers. Are you responding to the customer support ticket or responding to an alert on Slack? Say so in that Slack thread so other people can do something else. Are you blocked? Please say so. Mention what exactly you have tried and ask for ideas. We don't want to find out on the eve of the delivery date that you've been stuck for the past 1 week, and so the team won't be able to meet their deadline. When other people ask for help, and you are able to, please unblock them. You only get better by sharing with your team. Adopt open communication as much as possible. It will save you from having to private message 10 different people, on the same subject, to reach a decision. Just start a Slack thread in the channel, and everyone can contribute and reach a decision faster. It also helps with accountability and responsibility. What If? Seun Matt, "What if I do all these things and still do not get promoted? I am the resident expert, I know my stuff, I am proactive, and a great communicator. I have the basics covered, and I even set the standards. Despite all of this, I have not been promoted in years." I hear you loud and clear, my friend. We have all been there at some point. There are times when an organization is not able to perform pay raises or do promotions due to economic challenges, lack of profitability, and other prevailing market forces. Remember, the companies we work for do not print money, it is from their profit that they do promotions, raises and bonuses. For you, it is a win-win situation no matter how you look at it. These skill sets that you now have. The path you have taken they are all yours and applicable in the next company. In this profession, your next Salary is influenced by what you're doing at your current place and what you've done in the past. So, even if it does not work out in your current place, when you put yourself out there, you'll get a better offer, all things being equal. Conclusion No matter where you work, ensure you have a good experience. "I have done it before" trumps the number of years. In Software Engineering, experience is not just about the number of years you've worked in a company or have been coding. Experience has to do with the number of challenges you have solved yourself. How many "I have seen this before" you have under your belt? Being passive or just clocking in 9–5 will not get you that level of experience. You need to participate and lead. The interesting part is that your next salary in your next job will be determined by the experience you're garnering in your current work. Doing all of the above is a call of duty. It requires extra work, and it has extra rewards for those able to pursue it. Stay curious, see you at the top, and happy coding! Want to learn how to effectively evaluate the performance of Engineers? Watch the video below. Video More

When Incentives Sabotage Product Strategy

By Stefan Wolpers

CORE

TL;DR: When Incentives Sabotage Product Strategy Learn why many Product Owners and Managers worry about the wrong thing: saying no instead of saying yes to everything. This article reveals three systematic rejection techniques that strengthen stakeholder relationships while protecting product strategy to avoid organizational incentives sabotaging product strategy. Discover how those drive feature demands, why AI prototyping complicates strategic decisions, and how transparent Anti-Product Backlog systems transform resistance into collaboration. The Observable Problem: When Organizational Incentives Create Anti-Product Behaviors Product Owners and Managers often encounter a puzzling dynamic: stakeholders who champion features that clearly misalign with product strategy, resisting rejection with surprising intensity. While individual stakeholder psychology gets attention, the more powerful force may be systemic incentives that reward behaviors incompatible with desired product success. Charlie Munger’s observation proves relevant here: “Never, ever, think about something else when you should be thinking about the power of incentives.” Few forces shape human behavior more predictably than compensation structures, performance metrics, and career advancement criteria. Consider the sales director pushing for a dashboard feature that serves three enterprise prospects. Their quarterly bonus depends on closing those deals and rationalizing the feature request from their incentive perspective, even if it contradicts the product strategy. The customer support manager advocating for complex workflow automation may face performance reviews based on ticket resolution times, not customer satisfaction scores. These aren’t character flaws or political maneuvering. They’re logical responses to organizational incentive structures. Until Product Owners and Managers recognize incentive patterns driving stakeholder behavior, rejection conversations will address symptoms while ignoring causes. The challenge compounds when organizations layer agile practices onto unchanged incentive systems. Teams practice “collaborative prioritization,” while stakeholders receive bonuses for outcomes that require non-collaborative resource allocation. The resulting tension manifests as resistance to strategic rejection, which Product Owners and Managers often interpret as relationship problems rather than systems problems. The Generative AI Complication: When Low-Cost Prototyping Enables Poor Strategy Generative AI introduces a new dynamic that may make strategic rejection more difficult: the perceived reduction in experimentation costs. Stakeholders can now present Product Owners with quick prototypes, mockups, or even functioning code snippets, arguing that implementation costs have dropped dramatically: “Look, I already built a working prototype in an hour using Claude/ChatGPT/Copilot. How hard could it be just to integrate this?” becomes a common refrain. This generally beneficial capability creates an illusion that feature requests now carry minimal technical debt or opportunity cost. The fallacy proves dangerous: running more experiments doesn’t equate to delivering more outcomes. AI-generated prototypes may reduce initial development time, but don’t eliminate the strategic costs of unfocused Product Backlogs. Regardless of implementation speed, every feature (request) still requires user research, quality assurance, maintenance, support documentation, and, most critically, cognitive load from users navigating increasingly complex products. Worse, the ease of prototype generation may push teams toward what you may call the “analysis-paralysis zone:” endless experimentation without clear hypotheses or success criteria. When stakeholders can generate working demos quickly or assume the product team can, the pressure to “just try it and see” intensifies, potentially undermining the strategic discipline that effective product management requires. Product Owners need frameworks for rejecting AI-generated prototypes based on strategic criteria rather than technical feasibility. The question isn’t “Can we build this quickly?” but “Does this experiment advance our strategic learning objectives?” Questioning Assumptions About Stakeholder Collaboration The Agile Manifesto’s emphasis on “collaboration over contract negotiation” may create unintended consequences when stakeholder incentives misalign with product strategy. While collaboration generally produces better outcomes than adversarial relationships, some interpretations of collaboration may actually inhibit strategic clarity. Consider this hypothesis: endless collaboration on fundamentally misaligned requests might be less valuable than clear, well-reasoned rejection. This approach contradicts conventional wisdom about stakeholder management, which may not account for modern incentive complexity. The distinction between outcomes (measurable business results) and outputs (features shipped) becomes critical here. Stakeholder requests typically focus on outputs, possibly because their performance metrics reward feature delivery rather than business impact. However, optimizing for stakeholder comfort with concrete deliverables may create “feature factories,” organizations that measure success by shipping velocity rather than strategic advancement. Understanding stakeholder incentive structures seems essential for effective rejection conversations. Stakeholder requests aren’t inherently problematic, but they optimize for individual stakeholder success rather than product strategy coherence. Effective rejection requires acknowledging these incentive realities while maintaining strategic focus. The Strategic Framework: A Proven Decision-Making System to Avoid Incentives Sabotage Product Strategy The following Product Backlog management graphic illustrates a sophisticated and proven decision-making system that many Product Owners and Managers underutilize. It isn’t a theoretical framework; it represents battle-tested approaches to strategic resource allocation under constraint. The alignment-value pipeline concept demonstrates how ideas flow from multiple sources (stakeholder requests, user feedback, market data) through strategic filters (Product Goal, Product Vision) before reaching development resources. This systematic approach ensures that every feature request undergoes strategic evaluation rather than ad-hoc prioritization. The framework’s key strengths lie in its transparency and predictability. When the decision criteria are explicit and consistently applied, stakeholders can understand why their requests receive specific treatment. This transparency reduces political pressure and relationship friction because rejection feels systematic rather than personal. Moreover, it applies to everyone, regardless of position. The Anti-Product Backlog component proves particularly powerful for managing stakeholder relationships during rejection conversations. Rather than dismissing ideas, this approach documents rejected requests with clear strategic rationales, demonstrating respect for stakeholder input while maintaining product focus. The experimental validation loop directly addresses the generative AI challenge. Instead of building features because prototyping is easy, teams validate underlying hypotheses through structured experiments with measurable success criteria. This approach channels stakeholder enthusiasm for quick prototypes toward strategic learning rather than feature accumulation. The refinement color coding (green, orange, grey, white) provides tactical communication tools for managing stakeholder expectations. When stakeholders understand that development capacity is finite and strategically allocated, they may begin self-filtering inappropriate requests and presenting others more effectively. Technique One: Address Incentive Misalignments Before Feature Discussions Traditional rejection conversations focus on feature merit without addressing underlying incentive structures. This approach treats symptoms while ignoring causes, often leading to recurring requests for the same misaligned features. Consider starting rejection conversations by acknowledging stakeholder incentive realities: “I understand your quarterly goals include improving customer onboarding metrics, and this feature seems designed to address that objective. Let me explain why I think our current user activation experiments will have a greater impact on those same metrics.” This approach accomplishes several things: it demonstrates an understanding of stakeholder motivations, connects rejection to shared objectives, and redirects energy toward aligned solutions. You’re working within incentive structures rather than fighting them while maintaining strategic focus. For AI-generated prototypes, address the incentive to optimize for implementation speed over strategic value: “This prototype demonstrates technical feasibility, but before committing development resources, I need to understand the strategic hypothesis we’re testing and how we’ll measure success beyond technical implementation.” Document these incentive conversations as part of your Anti-Product Backlog entries. When stakeholders see their motivations acknowledged and addressed systematically, they’re more likely to trust future rejection decisions and collaborate on alternative approaches. Technique Two: Leverage Transparency as Strategic Protection The Anti-Product Backlog system provides more than rejection documentation: it creates transparency that protects Product Owners and Managers from political pressure while educating stakeholders about strategic thinking. Make your strategic criteria explicit and easily accessible. When stakeholders understand your decision framework before making requests, they can self-filter inappropriate ideas and present others more strategically. This transparency reduces rejection conversations by improving request quality. For each rejected item, document: The strategic misalignment (how does this conflict with Product Goal/Vision?)The opportunity cost (what strategic work would this displace?)The incentive analysis (what stakeholder objectives does this serve?)The alternative approaches (how else might we address the underlying need?)The reconsideration criteria (what would need to change to revisit this?) This systematic transparency serves multiple purposes: it demonstrates thoughtful analysis rather than arbitrary rejection, provides stakeholders with clear feedback on request quality, and creates precedent documentation that prevents the same arguments from recurring. Address AI prototype presentations with similar transparency: “I appreciate the technical exploration, but our Product Backlog prioritization depends on strategic alignment and validated user needs rather than implementation feasibility. Let me show you how this request fits into our current strategic framework.” Technique Three: Transform Rejection into Strategic Education Every rejection conversation represents an opportunity to educate stakeholders about strategic product thinking while addressing their underlying incentive pressures. Connect rejection rationales to measurable outcomes that align with stakeholder objectives: “I understand you need to improve support ticket resolution times. This feature might help marginally, but our planned user onboarding improvements could reduce ticket volume by 30% based on our support analysis, which would have a greater impact on your team’s performance metrics.” For AI-generated prototypes, use rejection as education about strategic experimentation: “This prototype shows what we could build, but effective product strategy requires understanding why we should build it and how we’ll know if it succeeds. Before committing to development, let’s define the strategic hypothesis and success criteria.” Reference the systematic process explicitly: “Our alignment-value pipeline shows 47 items in various stages representing 12 weeks of development work. This request would need to demonstrate higher strategic impact than current items to earn prioritization, and I don’t see evidence for that impact yet.” This educational approach gradually shifts stakeholder mental models from feature-focused to outcome-focused thinking. When stakeholders understand the true cost of product decisions and the strategic logic behind prioritization, they begin collaborating more effectively within strategic constraints rather than trying to circumvent them. The Incentive Reality: Systematic Causes Require Systematic Solutions Organizational incentives create predictable stakeholder behavior patterns that individual rejection conversations cannot address. Sales teams get compensated for promises that product teams must deliver. Marketing departments face engagement metrics that feature requests that could theoretically improve. Customer support managers need ticket resolution improvements that workflow automation might provide. These incentive structures aren’t necessarily wrong, but often conflict with product strategy coherence. Effective Product Owners and Managers must navigate these realities without compromising strategic focus. Building Systematic Rejection Capability Individual rejection conversations matter less than systematic practices that align organizational incentives with product strategy while maintaining stakeholder relationships. Consequently, establish regular stakeholder education sessions in which you share the alignment-value pipeline framework and demonstrate how strategic decisions are made. When stakeholders understand the system, they can work more effectively within it. Create metrics that track rejection effectiveness: ratio of strategic alignment in requests over time, stakeholder satisfaction despite rejections, value creation improvements from strategic focus, and business impact metrics from accepted features. Use Sprint Reviews to reinforce outcome-focused thinking by presenting strategic learning and business impact rather than just feature demonstrations. This gradually shifts organizational culture from output celebration to outcome achievement. Most importantly, recognize that strategic rejection isn’t about individual skills. Instead, it’s about organizational systems that either support or undermine strategic product thinking. Master systematic approaches, and you will build products that create a sustainable competitive advantage while maintaining stakeholder relationships based on mutual respect and strategic discipline, rather than diplomatic accommodation. Conclusion: Transform Your Strategic Rejection Skills Most Product Owners and Managers recognize these challenges but struggle with implementation. Reading frameworks doesn’t change entrenched stakeholder behavior patterns; systematic practice does. Start immediately: Document the incentive structures driving your three most persistent stakeholder requests. Create your first Anti-Product Backlog entry with a strategic rationale. Practice direct rejection language, focusing on strategic alignment rather than diplomatic deflection. More

Misunderstanding Agile: Bridging The Gap With A Kaizen Mindset

By Pabitra Saikia

How Security Engineers Can Help Build a Strong Security Culture

By Swati Babbar

When Agile Teams Fake Progress: The Hidden Danger of Status Over Substance

By Ella Mitkin

Software Specs 2.0: An Elaborate Example

This article is a follow-up to the article that lays the theoretical foundation for software requirement qualities. Here, I provide an example for how to craft requirements for a User Authentication Login Endpoint. A practical illustration of how essential software requirement qualities can be interwoven when designing specifications for AI-generated code. I demonstrate the crucial interplay between explicitness (to achieve completeness), unambiguity (for machine-first understandability), constraint definition (to guide implementation and ensure viability), and testability (through explicit acceptance criteria). We'll explore how these qualities can practically be achieved through structured documentation. Our goal is that our AI assistant has a clear, actionable blueprint for generating a secure and functional login service. For explanatory purposes and to make clear how things work, I will provide a detailed requirements document. A blueprint that is by no means exhaustive, but it can serve as the basis for understanding and expanding. Documentation can be lightweight in practice, but this article must focus on details to avoid confusion. The document starts by stating the requirement ID and title. A feature's description follows, along with its functional and non-functional requirements. Data definitions, implementation constraints, acceptance criteria, and error handling fundamentals are also documented. Requirement Document: User Authentication - Login Endpoint 1. Requirement ID and Title Unique IDs are crucial for traceability, allowing you to link this specific requirement to design documents, generated code blocks, and test cases. This helps in maintenance and debugging. ID: REQ-AUTH-001Title: User Login Endpoint 2. Feature Description The feature description provides a high-level overview and context. For AI, this helps establish the overall goal before diving into specifics. It answers the "what" at a broad level. This feature provides an API endpoint for registered users to authenticate themselves using their email address and password. Successful authentication will grant access by providing a session token. 3. Functional Requirements (FR) Functional requirements are broken down into atomic, specific statements. Keywords like MUST, SHOULD (though only MUST is used here for strictness) can follow RFC 2119 style, which AI-assistants can be trained to recognize. "Case-insensitive search," "structurally valid email format," and specific counter actions (increment, reset) leave little room for AI misinterpretation. This promotes unambiguity and precision. Details like checking if an account is disabled and the account lockout mechanism (FR11) cover crucial edge cases and security aspects, aiming for explicitness and completeness. FR1: The system MUST expose an HTTPS POST endpoint at /api/v1/auth/login.FR2: The endpoint MUST accept a JSON payload containing email (string) and password (string).FR3: The system MUST validate the provided email: FR3.1: It MUST be a non-empty string.FR3.2: It MUST be a structurally valid email format (e.g., [email protected]).FR4: The system MUST validate the provided password: FR4.1: It MUST comply with a strong password policy.FR5: If input validation (FR3, FR4) fails, the system MUST return an error (see Error Handling EH1).FR6: The system MUST retrieve the user record from the Users database table based on the provided email.FR7: If no user record is found for the email, or if the user account is marked as disabled, the system MUST return an authentication failure error (see Error Handling EH2).FR8: If a user record is found and the account is active, the system MUST verify the provided password against the stored hashed password for the user using the defined password hashing algorithm (see IC3: Security).FR9: If password verification fails, the system MUST increment a failed_login_attempts counter for the user and return an authentication failure error (see Error Handling EH2).FR10: If password verification is successful: FR10.1: The system MUST reset the failed_login_attempts counter for the user to 0.FR10.2: The system MUST generate a JSON Web Token (JWT) (see IC3: Security for JWT specifications).FR10.3: The system MUST return a success response containing the JWT (see Data Definitions - Output).FR11: Account lockout: If failed_login_attempts for a user reaches 5, their account MUST be temporarily locked for 15 minutes. Attempts to log in to a locked account MUST return an account locked error (see Error Handling EH3), even with correct credentials. 4. Data Definitions Clearly defining data definitions (schemas) for inputs and outputs is critical for AI to generate correct data validation, serialization, and deserialization logic. Using terms like "string, required, format: email" helps the AI map to data types and validation rules (e.g., when using Pydantic models). This contributes to Structured Input. Input Payload (JSON): email (string, required, format: email)password (string, required, minLength: 1)Success Output (JSON, HTTPS 200): access_token (string, JWT format)token_type (string, fixed value: "Bearer")expires_in(integer, seconds, representing token validity duration)Error Output (JSON, specific HTTPS status codes - see Error Handling): error_code (string, e.g., "INVALID_INPUT", "AUTH_FAILED", "ACCOUNT_LOCKED")message (string, human-readable error description) 5. Non-Functional Requirements (NFRs) NFRs reduce ambiguity, guide code generation toward aligned behaviors, and make the resulting software easier to verify against clearly defined benchmarks. They make qualities like performance and security testable and unambiguous. Specific millisecond targets and load conditions are set. Also, as an example, specific actions (no password logging, input sanitization) and references to further constraints (IC3) are provided. NFR1 (Performance): The average response time for the login endpoint MUST be less than 300ms under a load of 100 concurrent requests. P99 response time MUST be less than 800ms.NFR2 (Security): All password handling must adhere to security constraints specified in IC3. No sensitive information (passwords) should be logged. Input sanitization must be performed to prevent common injection attacks.NFR3 (Auditability): Successful and failed login attempts MUST be logged to the audit trail with timestamp, user email (for failed attempts, if identifiable), source IP address, and success/failure status. Failed attempts should include the specific failure reason (e.g., "user_not_found," "incorrect_password," "account_locked"). 6. Implementation Constraints and Guidance (IC) This section guides the AI's choices (Python/FastAPI, SQLAlchemy, Pydantic, bcrypt, JWT structure) without dictating the exact low-level code. For the purposes of this article, these specific choices are random and are not considered to be optimal in any sense. You are free to choose your own tech stack, architectural patterns, etc. Implementation constraints can guide towards Viability within the project's ecosystem and to meet specific security and architectural requirements. Also, it should be mentioned that the constraints shown are indicative and are by no means exhaustive. Currently, it depends on the specific AI assistant and the project under development, which constraints are more appropriate. Will there be AI assistants that develop code perfectly without constraints and guidance from humans? It remains to be seen. IC1 (Technology Stack): Backend Language/Framework: Python 3.11+ / FastAPI.Data Validation: Pydantic models derived from Data Definitions.Database Interaction: Use SQLAlchemy ORM with the existing project database session configuration. Target table: Users.IC2 (Architectural Pattern): Logic should be primarily contained within a dedicated AuthenticationService class. The API endpoint controller should delegate to this service.IC3 (Security - Password and Token): Password Hashing: Stored passwords MUST be hashed using bcrypt with a work factor of 12.JWT Specifications: Algorithm: HS256.Secret Key: Retrieved from environment variable JWT_SECRET_KEY.Payload Claims: MUST include sub (user_id), email, exp (expiration time), iat (issued at).Expiration: Tokens MUST expire 1 hour after issuance.IC4 (Environment): The service will be deployed as a Docker container. Configuration values (like JWT_SECRET_KEY, database connection string) MUST be configurable via environment variables.IC5 (Coding Standards): Adhere to PEP 8 style guide.All functions and methods MUST include type hints.All public functions/methods MUST have docstrings explaining purpose, arguments, and return values. 7. Acceptance Criteria (AC - Gherkin Format) Acceptance criteria make the requirements Testable. Gherkin is an example format that is human-readable and structured. A behaviour-driven development tool that can also be used for AI assistants to derive specific test cases. It can cover happy paths and key error/edge cases, providing concrete examples of expected behavior. This gives clear verification targets for the AI-generated code. Plain Text Feature: User Login API Endpoint Background: Given a user "[email protected]" exists with a bcrypt hashed password for "ValidPassword123" And the user account "[email protected]" is not disabled And the user "[email protected]" has 0 failed_login_attempts And the JWT_SECRET_KEY environment variable is set Scenario: Successful Login with Valid Credentials When a POST request is made to "/api/v1/auth/login" with JSON body: """ { "email": "[email protected]", "password": "ValidPassword123" } """ Then the response status code should be 200 And the response JSON should contain an "access_token" (string) And the response JSON should contain "token_type" with value "Bearer" And the response JSON should contain "expires_in" with value 3600 And the "access_token" should be a valid JWT signed with HS256 containing "sub", "email", "exp", "iat" claims And the failed_login_attempts for "[email protected]" should remain 0 Scenario: Login with Invalid Password When a POST request is made to "/api/v1/auth/login" with JSON body: """ { "email": "[email protected]", "password": "InvalidPassword" } """ Then the response status code should be 401 And the response JSON should contain "error_code" with value "AUTHENTICATION_FAILED" And the response JSON should contain "message" with value "Invalid email or password." And the failed_login_attempts for "[email protected]" should be 1 Scenario: Login with Non-Existent Email When a POST request is made to "/api/v1/auth/login" with JSON body: """ { "email": "[email protected]", "password": "AnyPassword" } """ Then the response status code should be 401 And the response JSON should contain "error_code" with value "AUTHENTICATION_FAILED" And the response JSON should contain "message" with value "Invalid email or password." Scenario: Account Lockout after 5 Failed Attempts Given the user "[email protected]" has 4 failed_login_attempts When a POST request is made to "/api/v1/auth/login" with JSON body: # This is the 5th failed attempt """ { "email": "[email protected]", "password": "InvalidPasswordAgain" } """ Then the response status code should be 403 And the response JSON should contain "error_code" with value "ACCOUNT_LOCKED" And the response JSON should contain "message" with value "Account is temporarily locked due to too many failed login attempts." And the failed_login_attempts for "[email protected]" should be 5 8. Error Handling (EH) This dedicated error handling section ensures Completeness by explicitly defining how different failure scenarios are communicated. To improve completeness we need to extensively cover edge cases and error handling. Specify exactly how different errors (validation errors, system errors, network errors) should be caught, logged, and communicated to the user (specific error messages, codes). EH1 (Invalid Input): Trigger: FR3 or FR4 fails.HTTPS Status: 400 Bad Request.Response Body: { "error_code": "INVALID_INPUT", "message": "Invalid input. Email must be valid and password must not be empty." } (Example message, could be more specific based on which field failed).EH2 (Authentication Failure): Trigger: FR7 or FR9 occurs.HTTPS Status: 401 Unauthorized.Response Body: { "error_code": "AUTHENTICATION_FAILED", "message": "Invalid email or password." } (Generic message to prevent user enumeration).EH3 (Account Locked): Trigger: Attempt to log in to an account that is locked per FR11.HTTP Status: 403 Forbidden.Response Body: { "error_code": "ACCOUNT_LOCKED", "message": "Account is temporarily locked due to too many failed login attempts." } Final Remarks The dual purpose. The example User Authentication Login Endpoint requirement is carefully chosen so that it can be used for two purposes. The first is to explain the basic qualities of software requirements, irrespective of who writes the code (a human or AI). The second purpose is to focus on AI-assisted code and how to use requirements to our advantage.Examples used are not exhaustive. All data and examples presented in the eight paragraphs, from requirement ID and title to error handling, are indicative. Many more functional/non-functional requirements can be crafted, as well as data definitions. Acceptance criteria and error handling cases are a minimal sample of what is usually needed in practice. Negative constraints (don't use Z, avoid pattern A), for example, are not provided here but can be very beneficial as well. And of course, you may find that there are other paragraphs, beyond the scope of this article, that are tailored to your documentation needs.Documentation is not static. For clarity and completeness in this article, the documentation for the User Authentication Login Endpoint seems to be static. All is well specified upfront and then fed to the AI-assistant that does the job for us. Although a detailed document can be a good starting point, factors like implementation constraints and guidance can be fully interactive. For AI assistants, for example, with sophisticated chat interfaces, a "dialogue" with AI can be an important part of the process. While initial implementation constraints can be vital, some constraints might be refined or even discovered through interaction with the AI. Wrapping Up I provided a requirements document for a User Authentication Login Endpoint requirement. This example document attempts to be explicit, precise, and constrained. Software requirements must necessarily be viable whilst eminently testable. It's structured to provide an AI code generator with sufficient detail to minimize guesswork and the chances of the AI producing undesirable output. While AI code assistants will probably be more capable and context-aware, the fundamental need for human-defined guidance appears to remain. Guiding an AI assistant for software development could be embedded in project templates. It could be via custom AI assistant configurations (if available), or even as part of a "system prompt" that always precedes specific task prompts. A dynamic set of principles that inform an ongoing interaction with AI can be based on the following. Initial scaffolding: We provide the critical initial direction, ensuring the AI starts on the right path aligned with project standards, architecture, and non-negotiable requirements (especially security).Basis for interaction: Our documentation becomes the foundation for interactive refinement. When the AI produces output, it can be evaluated against our documented requirements.Evolving knowledge base: As the project progresses, parts of our documentation can be updated, or new ones added, reflecting new decisions or learnings.Guardrails for AI autonomy: As AIs gain more autonomy in suggesting larger code blocks or even architectural components, such documents can act as essential guardrails, ensuring their "creativity" stays within acceptable project boundaries.

By Stelios Manioudakis, PhD

CORE

What They Don’t Teach You About Starting Your First IT Job

From Certification to Chaos You’ve got your first tech job. You’re excited, you’re nervous—and within the first week, you’re confused. Everyone talks about sprints, blockers, Jira, and velocity. But what didn’t they mention in your certification course? Real life doesn’t run by the book. You won’t find answers for every work situation in your Scrum manual or your college lecture notes. You might not even know who to ask when something feels off. This article is for the newly hired, bright-eyed Agile junior who’s suddenly face-to-face with live fire delivery, inconsistent process, and team dynamics that no Udemy course prepared them for. Here’s what you actually need to know to survive — and thrive — as a junior in an Agile team. 1. Your Certification Isn’t a Playbook Scrum may be clean on paper, but most real-world projects are messy. You’ll see: Product Owners running backlog in ExcelStandups that stretch into status meetingsTools “coming soon,” but never configuredRetrospectives that are skipped or treated like a therapy circle Your training may give you structure, but reality will test your flexibility. The point of a framework is to provide a shared language, not a rigid checklist. Agile isn’t about perfection — it’s about iteration. When the tooling is clunky or meetings derail, take notes. Ask what should be happening, and help realign your expectations without becoming cynical. Pro tip: Keep a personal reflection log. Each sprint, note what surprised you and what felt unclear. These reflections will accelerate your learning far more than memorizing theoretical roles. Also, observe how different teams interpret Agile. One may run Kanban with strict WIP limits, another blends Scrum with biweekly chaos. Your flexibility and observational skills will become part of your skill set. Don’t assume something is “wrong” just because it looks different from training. 2. Learn From the Quiet Pros Every team has a quiet star — the one who leads calmly under pressure, speaks clearly, and never gets into political battles. They might not be loud on Slack, but their ideas carry weight when they speak. Watch them. Learn their patterns. Copy their style. That’s your mentorship loop — even if it’s unofficial. Mentors help you avoid mistakes. Copy their working habits, then keep improving yours. Ask to shadow their refinement sessions. Watch how they write Jira tickets. Observe how they handle feedback. These micro-patterns are often more valuable than onboarding documents. If you're unsure how to approach someone, ask: "I'm still new and want to understand how experienced teammates work. Would you be open to me sitting in on a few of your task breakdowns or estimation calls?" Most pros will say yes, and respect you for it. Also, remember: not all mentorship is top-down. Sometimes your best learning comes from a peer who joined six months before you. Don’t over-glorify titles. Look for consistency, clarity, and results. 3. Don’t Let Pride Delay Delivery This one is critical: Asking for help early makes you reliable, not weak. I’ve seen juniors try to prove themselves by grinding alone through a task that should take 30 minutes, but instead takes 8 hours. End result? Missed deadlines, frustrated teammates, unnecessary escalations. In Agile teams, transparency matters more than heroism. What good juniors do: Ask early and clarify oftenShare blockers without shameUpdate tickets and leave comments What struggling juniors often do: Stay silent, hoping to solve it aloneDelay feedback loopsPush blame when the review fails Good communication prevents bad performance. Speak up before the sprint report does. Additionally, it helps to understand the psychology behind asking for help. Many juniors fear being seen as unprepared — but the opposite is true: teams trust you more when you show you're willing to get things right, not just done. Normalize saying, “I don’t know yet, but I want to understand.” 4. Your Role Is More Than Your Code Even if you're hired as a tester, developer, or analyst, your value isn’t just execution. Your team needs: Clear written commentsTestable user storiesHonest estimatesRisk callouts You’re not a pair of hands. You’re a thinking partner. In your first few months, make it a habit to: Ask why a user story mattersRepeat goals during planning to check alignmentSuggest improvements to the process, even if minor Also: Clarify requirements before coding startsFlag vague or risky acceptance criteriaBe the person who connects documentation to implementation These habits will not only boost your reputation — they’ll also make life easier for your testers, product owners, and reviewers. Even if your technical skills are still growing, your ability to create flow will earn you trust fast. 5. Feedback Is Gold — Not a Threat Feedback might feel intimidating at first. No one likes hearing that their code could be cleaner or that their analysis is too vague. But real feedback is one of the fastest career accelerators. Here’s how to embrace it: Treat every code review comment as a mini-lessonAsk for feedback even when it’s not offeredLearn to differentiate between tone and intention If a senior comments, “naming could be clearer,” don’t take it personally — take it seriously. Review their naming conventions. Ask what they'd suggest. This attitude builds collaboration and positions you as someone who wants to grow. Teams don’t expect perfection from juniors. They expect responsiveness and the willingness to evolve. Make it obvious that you are here to get better. Final Thoughts: Don’t Fake It—Shape It Breaking into IT isn’t about looking flawless. It’s about staying coachable. If you: Ask good questionsStay curiousAdapt with intention ...you’ll outperform people who try to fake expertise. Your first job isn’t the end of learning — it’s the real beginning. The difference between juniors who grow and those who stall isn’t talent. It’s honesty, consistency, and the humility to listen. Stay sharp. Stay human. Stay in the loop. You were hired because someone believed in your potential. Keep proving them right — not by being perfect, but by being present.

By Ella Mitkin

AI-Native Platforms: The Unstoppable Alliance of GenAI and Platform Engineering

Let's be honest. Building developer platforms, especially for AI-native teams, is a complex art, a constant challenge. It's about finding a delicate balance: granting maximum autonomy to development teams without spiraling into chaos, and providing incredibly powerful, cutting-edge tools without adding superfluous complexity to their already dense workload. Our objective as Platform Engineers has always been to pave the way, remove obstacles, and accelerate innovation. But what if the next, inevitable phase of platform evolution wasn't just about what we build and provide, but what Generative AI can help us co-build, co-design, and co-manage? We're not talking about a mere incremental improvement, a minor optimization, or a marginal new feature. We're facing a genuine paradigm shift, a conceptual earthquake where artificial intelligence is no longer merely the final product of our efforts, the result of our development toils, but becomes the silent partner, the tireless ally that is already reimagining, rewriting, and redefining our entire development experience. This is the real gamble, the challenge that awaits us: transforming our platforms from simple toolsets, however sophisticated, into intelligent, dynamic, and self-optimizing ecosystems. A place where productivity isn't just high, but exceptionally high, and innovation flows frictionlessly. What if We Unlock 100% of Our Platform’s Potential? Your primary goal, like that of any good Platform Engineer, is already to make developers' lives simpler, faster, and, let's admit it, significantly more enjoyable. Now, imagine endowing your platform with genuine intelligence, with the ability to understand, anticipate, and even generate. GenAI, in this context, isn't just an additional feature that layers onto existing ones; it's the catalyst that is already fundamentally redefining the Developer Experience (DevEx), exponentially accelerating the entire software development lifecycle, and, even more fascinating, creating new, intuitive, and natural interfaces for interacting with the platform's intrinsic capabilities. Let's momentarily consider the most common and frustrating pain points that still afflict the average developer: the exhaustive and often fruitless hunt through infinite and fragmented documentation, the obligation to memorize dozens, if not hundreds, of specific and often cryptic CLI commands, or the tedious and repetitive generation of boilerplate code. With the intelligent integration of GenAI, your platform magically evolves into a true intelligent co-pilot. Imagine a developer who can simply express a request in natural language, as if speaking to an expert colleague: "Provision a new staging environment for my authentication microservice, complete with a PostgreSQL database, a dedicated Kafka topic, and integration with our monitoring system." The GenAI-powered platform not only understands the deep meaning and context of the request, not only translates the intention into a series of technical actions, but executes the operation autonomously, providing immediate feedback and magically configuring everything needed. This isn't mere automation, which we already know; it's a conversational interaction, deep and contextual, that almost completely zeroes out the developer's cognitive load, freeing their mind and creative energies to focus on innovation, not on the complex and often tedious infrastructural "plumbing". But the impact extends far beyond simple commands. GenAI can act as an omnipresent expert, an always-available and incredibly informed figure, providing real-time, contextual assistance. Imagine being stuck on a dependency error, a hard-to-diagnose configuration problem, or a security vulnerability. Instead of spending hours searching forums or asking colleagues, you can ask the platform directly. And it, magically, suggests practical solutions, directs you to relevant internal best practices (perhaps your own guides, finally usable in an intelligent way!), or even proposes complete code patches to solve the problem. It can proactively identify potential security vulnerabilities in the code you've just generated or modified, suggest intelligent refactorings to improve performance, or even scaffold entire new modules or microservices based on high-level descriptions. This drastically accelerates the entire software development lifecycle, making best practices inherent to the process and transforming bottlenecks into opportunities for automation. Your platform is no longer a mere collection of passive tools, but an intelligent and proactive partner at every single stage of the developer's workflow, from conception to implementation, from testing to deployment. Crucially, for this to work, the GenAI model must be fed with the right platform context. By ingesting all platform documentation, internal APIs, service catalogs, and architectural patterns, the AI becomes an unparalleled tool for discoverability of platform items. Developers can now query in natural language to find the right component, service, or golden path for their needs. Furthermore, this contextual understanding allows the AI to interrogate and access all data and assets within the platform itself, as well as from the applications being developed on it, providing insights and recommendations in real-time. This elevates the concept of a composable architecture, already enabled by your platform, to an entirely new level. With an AI co-pilot that not only knows all available platform items but also understands how to use them optimally and how others have used them effectively, the development of new composable applications or rapid Proofs of Concept (PoCs) becomes faster than ever before. The new interfaces enabled by GenAI go beyond mere suggestion. Think of natural language chatbot interfaces for giving commands, where the platform responds like a virtual assistant. Crucially, thanks to advancements like Model Context Protocol (MCP) or similar tool-use capabilities, the GenAI-powered platform can move beyond just "suggesting" and actively "doing". It can execute complex workflows, interact with external APIs, and trigger actions within your infrastructure. This fosters a true cognitive architecture where the model isn't just generating text but is an active participant in your operations, capable of generating architectural diagrams, provisioning resources, or even deploying components based on a simple natural language description. The vision is that of a "platform agent" or an "AI persona" that learns and adapts to the specific needs of the team and the individual developer, constantly optimizing their path and facilitating the adoption of best practices. Platforms: The Launchpad for Ai-Powered Applications This synergy is two-way, a deep symbiotic relationship. If, on one hand, GenAI infuses new intelligence and vitality into platforms, on the other, your Internal Developer Platforms are, and will increasingly become, the essential launchpad for the unstoppable explosion of AI-powered applications. The complex and often winding journey of an artificial intelligence model—from the very first phase of experimentation and prototyping, through intensive training, to serving in production and scalable inference—is riddled with often daunting infrastructural complexities. Dedicated GPU clusters, specialized Machine Learning frameworks, complex data pipelines, and scalable, secure, and performant serving endpoints are by no means trivial for every single team to manage independently. And this is where your platform uniquely shines. It has the power to abstract away all the thorny and technical details of AI infrastructure, providing self-service and on-demand provisioning of the exact compute resources (CPU, various types of GPUs), storage (object storage, data lakes), and networking required for every single phase of the model's lifecycle. Imagine a developer who has just finished training a new model and needs to deploy an inference service. Instead of interacting with the Ops team for days or weeks, they simply request it through an intuitive self-service portal on the platform, and within minutes, the platform automatically provisions the necessary hardware (perhaps a dedicated GPU instance), deploys the model to a scalable endpoint (e.g., a serverless service or a container on a dedicated cluster), and, transparently, even generates a secure API key for access and consumption. This process eliminates days or weeks of manual configuration, of tickets and waiting times, transforming a complex and often frustrating MLOps challenge into a fluid, instant, and completely self-service operation. The platform manages not only serving but the entire lifecycle: from data preparation, to training clusters, to evaluation and A/B testing phases, all the way to post-deployment monitoring. Furthermore, platforms provide crucial golden paths for AI application development at the application layer. There's no longer a need for every team to reinvent the wheel for common AI patterns. Your platform can offer pre-built templates and codified best practices for integrating Large Language Models (LLMs), implementing patterns like Retrieval-Augmented Generation (RAG) with connectors to your internal data sources, or setting up complete pipelines for model monitoring and evaluation. Think of robust libraries and opinionated frameworks for prompt engineering, for managing model and dataset versions, for specific AI model observability (e.g., tools for bias detection, model interpretation, or drift management). The platform becomes a hub for collaboration on AI assets, facilitating the sharing and reuse of models, datasets, and components, including the development of AI agents. By embedding best practices and pre-integrating the most common and necessary AI services, every single developer, even one without a deep Machine Learning background, is empowered to infuse their applications with intelligent, cutting-edge capabilities. This not only democratizes AI development across the organization but unlocks unprecedented innovation that was previously limited to a few specialized teams. The Future Is Symbiotic: Your Next Move The era of AI-native development isn't an option; it's an imminent reality, and it urgently demands AI-native platforms. The marriage of GenAI and Platform Engineering isn't just an evolutionary step; it's a revolutionary leap destined to redefine the very foundations of our craft. GenAI makes platforms intrinsically smarter, more intuitive, more responsive, and consequently, incredibly more powerful. Platforms, in turn, provide the robust, self-service infrastructure and the well-paved roads necessary to massively accelerate the adoption and deployment of AI across the enterprise, transforming potential into reality. Are you ready to stop building for AI and start building with AI? Now is the time to act. Identify the most painful bottlenecks in your current DevEx and think about how GenAI could transform them. Prioritize the creation of self-service capabilities for AI infrastructure, making model deployment as simple as that of a traditional microservice. Cultivate a culture of "platform as a product", where AI is not just a consumer, but a fundamental feature of the platform itself. The future of software development isn't just about AI-powered applications; it's about an AI-powered development experience that completely redefines the concepts of productivity, creativity, and the very act of value creation. Embrace this unstoppable alliance, and unlock the next fascinating frontier of innovation. The time of static platforms is over. The era of intelligent platforms has just begun.

By Graziano Casto

CORE

DevOps in the Cloud - How to Streamline Your CI/CD Pipeline for Multinational Teams

Modern software development is inherently global. Distributed engineering teams collaborate across time zones to build, test, and deploy applications at scale. DevOps, the practice of combining software development (Dev) and IT operations (Ops), is essential to achieving these goals efficiently. One of the primary challenges in this setting is simplifying the Continuous Integration and Continuous Delivery (CI/CD) pipeline in the cloud, enabling global teams to collaborate seamlessly. Challenges of Managing Multinational Teams Operating in multiple countries offers significant opportunities, but it also comes with challenges, particularly for multinational software teams. Time zone differences: Delays in communication and handoffs.Regulatory compliance: Adhering to local data laws (e.g., GDPR, HIPAA).Communication barriers: Language and cultural differences.Legal and financial complexities: Tax, residency, and operational scaling. Just as containerization standardizes deployment environments, a well-architected CI/CD pipeline acts as the "universal runtime" for global software delivery. Additionally, legal and financial complexities make scaling global operations even harder. Interestingly, the concept of the second passport comes into play here for executives and technical leaders who work across borders. A second passport allows individuals to manage travel, residency, and tax considerations more flexibly, easing the process of leading multinational teams without the hindrance of jurisdictional restrictions. Similarly, a streamlined CI/CD pipeline can act as a technological passport, enabling developers and engineers to move code efficiently across the globe. CI/CD Pipelines: The Backbone of DevOps The CI/CD pipeline is the backbone of any successful DevOps strategy, ensuring that code is tested, integrated, and deployed automatically, allowing teams to focus on innovation rather than manual processes. For multinational teams, it’s especially critical that these pipelines must be, Reliable: Minimizing failures in distributed environments.Fast: Reducing delays caused by time zone differences.Scalable: Supporting a geographically diverse workforce. In a DevOps ecosystem, seamless CI/CD pipelines prevent bottlenecks, enabling teams to develop, test, and deploy features or bug fixes quickly, regardless of their location. CI/CD: The Nervous System of Modern Software Delivery For engineering teams shipping code internationally, CI/CD pipelines must be: Deterministic: Same commit, same result in any regionLow-latency: Fast feedback loops despite geographical dispersionObservable: Granular metrics on build times, test flakes, deployment success Example: A team in Berlin merges a hotfix that automatically triggers: Parallelized testing in AWS us-east-1 and ap-southeast-1Compliance checks for data residency requirementsCanary deployment to Tokyo edge locations Some of the leading Cloud Providers for DevOps are listed below, along with their key strengths. Platform DevOps Advantage Ideal For AWS Broad DevOps tools, global data centers, strong compliance Teams needing global redundancy Azure Seamless integration for Microsoft-based enterprises Microsoft ecosystem shops Google Cloud Superior Kubernetes & container orchestration Kubernetes-native organizations Building a Unified DevOps Culture Across Borders DevOps isn’t just a set of tools and processes - it’s a culture that promotes collaboration, continuous improvement, and innovation. For multinational teams, building a unified DevOps culture is critical to ensuring that everyone is aligned toward the same objectives. This begins with focusing on open communication and collaboration tools that work seamlessly across different time zones and languages. To create a cohesive culture, organizations need to adopt common workflows, coding standards, and development philosophies. Encouraging transparency and responsibility will help team members from various nations work more effectively together. Furthermore, supporting this alignment are frequent team sync-ups, cross-border information sharing, and a feedback culture. Automation in CI/CD Pipelines: A Global Necessity Manual interventions in distributed teams lead to delays. Automation eliminates these bottlenecks by: Automated testing: Ensuring code quality before deployment.Automated deployments: Enabling 24/7 releases across time zones.Consistent standards: Reducing human error. In global teams, time zone differences can result in significant delays caused by manual interventions. By automating key stages of the pipeline, teams can push code updates and new features around the clock, ensuring that business never stops, no matter where developers are located. Automated tools like Jenkins: Open-source automation server.Travis CI: Cloud-based CI for GitHub projects.CircleCI: Fast, scalable pipeline automation. Collaboration Tools for Multinational DevOps Teams DevOps processes rely on effective teamwork, especially when team members are distributed globally. Many tools support project management and continuous communication, enabling teams to remain in agreement even across great distances. Slack: Instant messaging and integrations.Jira: Agile project management and issue tracking.GitHub/GitLab: Code collaboration and version control. Cloud-Native CI/CD Solutions for Global Scalability As global teams grow, scalability becomes a key concern. Cloud-native CI/CD solutions, such as Kubernetes, Docker, and Terraform, are ideal for multinational organizations looking to scale their operations without sacrificing efficiency. These tools enable teams to deploy applications in any region, leveraging cloud infrastructure to manage containers, orchestrate workloads, and ensure uptime across multiple time zones. Using cloud-native technologies enables international teams to quickly meet evolving corporate needs and deliver benefits to consumers worldwide. Kubernetes, in particular, offers seamless orchestration for containerized applications, allowing teams to manage their CI/CD pipelines more effectively. Managing Compliance and Security in Multinational CI/CD Pipelines Security and regulatory compliance are major concerns for global teams, especially when operating in countries with stringent data protection laws. CI/CD pipelines must be designed to ensure that code complies with local regulations, including GDPR in Europe or HIPAA in the United States. Multinational teams must incorporate security best practices into their development pipelines, including automated vulnerability scanning and secure deployment practices. Additionally, ensuring that data is stored and processed in compliance with local laws is crucial for avoiding potential legal issues in the future. Monitoring and Optimizing Global DevOps Performance Real-time insights help teams maintain efficiency: Prometheus: Metrics monitoring.Grafana: Visualization and analytics.Datadog: Full-stack observability. Tracking deployment frequency, lead time, and failure rates helps optimize performance. Real-World Case Studies: Successful Global DevOps Implementations To better understand the benefits of streamlining CI/CD pipelines for multinational teams, it’s useful to look at real-world examples. Companies like Netflix, Amazon, and Spotify have successfully implemented global DevOps strategies that leverage cloud infrastructure and automation to streamline their workflows. These companies have adopted cloud-native technologies and automated their CI/CD pipelines, allowing them to scale quickly and deploy updates to users worldwide. By following their example, other multinational teams can achieve similar success. Future-Proofing Your CI/CD Pipeline for Global Growth As global collaboration becomes more common, it’s crucial for organizations to streamline their CI/CD pipelines in the cloud to support multinational teams. Businesses can future-proof their CI/CD pipelines and guarantee they are ready for worldwide expansion by using cloud-native tools, automating important operations, and creating a consistent DevOps culture. Streamlining DevOps in the cloud is not only about efficiency but also about enabling teams to collaborate seamlessly across borders. Through automation, security best practices, or real-time monitoring, a well-optimized CI/CD pipeline will determine the course of global software development.

By Fawad Malik

Revolutionizing Software Development: Agile, Shift-Left, and Cybersecurity Integration

Software development evolved dramatically since the days of waterfall project management. Today, reliability and security are more prominent in product expectations—usable, secure, and defect-free software is the gold standard. The shift-left Agile approach addresses these concerns by facilitating quicker turnaround times, incremental deliverables, more frequent client input, and higher success rates. In a typical Agile workflow, teams start the planning and development process on the left and move to the right as a project enters production. Where security and quality assurance were introduced later in the process, shift-left leverages Agile practices to include testing for bugs at the earliest planning and development stages. This approach reduces the likeliness of significant flaws and vulnerabilities entering the production phase and eventually being shipped out to customers. Shift-left addresses concerns as they arise with early testing and automation, facilitating smoother and faster integration and deployment. In a successful shift-left scenario, software quality is high, automation is effective, and customer experience is improved. Save Time and Money with Early Fixes A well-known study by the National Institute of Standards and Technology (NSIT)—“Impact of Inadequate Software Testing Infrastructure,” highlights how poor testing practices affect the economy. The study reveals that gaps in testing cost the U.S. economy about $59.5 billion per year. Another study by CrossTalk found that companies take up to 150 times longer to remediate an issue found in production than earlier during the requirements stage. Statistics like these make the case for shifting testing left, thereby allowing teams to identify and address flaws early. Today’s software development lifecycles (SDLCs) include considerable collaboration efforts that require complex webs of interconnected tools and components, from open-source and commercial tools to cloud configuration files and deployment specifications. With so many moving parts, quality assurance and security are an ongoing challenge. Working under pressures to speed up production and take on ever-greater workloads, developers can also become incentivized to overlook security standards. A 2023 study surveyed 500 developers and found that 77 percent had taken on increased resonsibilities for additional code testing in the last year, while 67 percent reported pushing code to production without testing. While shift-left may cost more resources in the short term, in most cases, the long-term savings more than make up for the initial investment. Bugs discovered after a product release can cost up to 640 times more than those caught during development. In addition, late detection can increase the risk of fines from security breaches, as well as causing damage to a brand’s trust. Automation tools are the primary answer to these concerns and are at the core of what makes shift-left possible. The popular tech industry mantra, “automate everything,” continues to apply. Static analysis, dynamic analysis, and software composition analysis tools scan for known vulnerabilities and common bugs, producing instant feedback as code is first merged into development branches. In recent years, vendors such as Gitlab, GitHub, Azure DevOps, and others have developed built-in code scanning applications, allowing teams to move forward quickly and avoid reinventing the wheel. Shift-left In Practice Like most software strategies, shift-left initiatives vary from company to company based on business context, with the common denominator being visibility early in the software assembly stage. Developers at IBM have credited automation of cloud infrastructure and containerization as key elements of their shift-left approach. Containers—bundles of software executables that include all the dependencies and libraries they need to run—allow for greater portability and less friction between testing environments. IBM’s automated toolchain scans each container for flaws and vulnerabilities in source code, cloud configurations, and third-party integrations. Each pull request is automatically tested for traditional bugs and its impact on the entire CI/CD pipeline, which includes big-picture compliance and security checks. Microsoft has referenced the importance of organizational structure and team communication when discussing shift-left initiatives. Key challenges for Microsoft included inconsistent coding standards across teams and siloed communications. Its solution involved the creation of a central team that focused on “developing a common engineering system based on Microsoft Azure DevOps, while driving consistency across the organization regarding how they design, code, instrument, test, build, and deploy services.” Best Practices Shift-left can only be built upon a solid DevOps foundation. Common pitfalls of failed shift-left initiatives are ineffective application of tools and misaligned goals among stakeholders. It is essential for an implementation plan and change management strategy to be developed to create clear, actionable steps for developers to take. Best practices begin with introducing appropriate automation tools, which are fine-tuned according to an organization’s use case. It is also crucial for developers to be set up to succeed with the necessary support, point people to go to with questions, and adequate training on processes and tools. When approached strategically, shift-left can make developers’ daily tasks easier rather than harder. The instant feedback afforded by automation tools can reduce the need to task-switch and review existing code. Beyond out-of-the-box solutions, shift-left automation examples include apps like internal dashboards for observability and custom development portals for error tracking, resources, and alerts. Open dialog can help ensure developers benefit from the tools acquired and built. Once applied, the business impact of shift-left can be measured with metrics like cost comparisons, number of defects, number of support tickets, and customer surveys. Trending Toward AI The future of shift-left includes more automation and integration of AI. Code reviews are a critical part of the SDLC—today, most of this work is still done manually. Senior developers often spend valuable time reviewing their team’s code to ensure quality. This process is changing with the rise of AI tools like GitHub Copilot and GitLab Duo. These AI-driven systems can handle code reviews automatically, saving time and boosting code quality. In 2024, GitHub Advanced Security (GHAS) rolled out an AI-assisted code scanner, which included auto-fix suggestions based on the CodeQL engine. A range of comparable options in this AI-driven space include application security scanning tools like Synopsys, Veracode, Checkmarx, and Contrast. Of course, these tools aren’t cheap—licenses can be expensive for companies. But once they’re in place, they can make a huge difference in how teams work and in the broader job market. If code reviews can be fully automated with AI tools, senior developer roles could change dramatically along with the concept of expertise in development teams. Speed, Quality, and Consistency Shift-left balances speed with quality. Performing regular checks on code as it is written reduces the likelihood that significant defects and vulnerabilities will surface after a release. Once software is out in the wild, the cost to fix issues is much higher and requires extensively more work than catching them in the early phases. Despite the advantages of shift-left, navigating the required cultural change can be a challenge. As such, it’s crucial for developers to be set up for success with effective tools and proper guidance. When security and quality are managed proactively with these key elements, products have a higher chance of success, and the full benefits of Agile and shift-left are realized.

By Vasdev Gullapalli

The Truth About AI and Job Loss

I keep finding myself in conversations with family and friends asking, “Is AI coming for our jobs?” Which roles are getting Thanos-snapped first? And will there still be space for junior individual contributors in organizations? And many more. With so many conflicting opinions, I felt overwhelmed and anxious, so I decided to take action instead of staying stuck in uncertainty. So, I began collecting historical data and relevant facts to gain a clearer understanding of the direction and impact of the current AI surge. So, Here’s What We Know Microsoft reports that over 30% of the code on GitHub Copilot is now AI-generated, highlighting a shift in how software is being developed. Major tech companies — including Google, Meta, Amazon, and Microsoft — have implemented widespread layoffs over the past 18–24 months. Current generative AI models, like GPT-4 and CodeWhisperer, can reliably write functional code, particularly for standard, well-defined tasks.Productivity gains: Occupations in which many tasks can be performed by AI are experiencing nearly five times higher growth in productivity than the sectors with the least AI adoption.AI systems still require a human “prompt” or input to initiate the thinking process. They do not ideate independently or possess genuine creativity — they follow patterns and statistical reasoning based on training data.Despite rapid progress, today’s AI is still far from achieving human-level general intelligence (AGI). It lacks contextual awareness, emotional understanding, and the ability to reason abstractly across domains without guidance or structured input.Job displacement and creation: The World Economic Forum's Future of Jobs Report 2025 reveals that 40% of employers expect to reduce their workforce where AI can automate tasks.And many more. There’s a lot of conflicting information out there, making it difficult to form a clear picture. With so many differing opinions, it's important to ground the discussion in facts. So, let’s break it down from a data engineer’s point of view — by examining the available data, identifying patterns, and drawing insights that can help us make sense of it all. Navigating the Noise Let’s start with the topic that’s on everyone’s mind — layoffs. It’s the most talked-about and often the most concerning aspect of the current tech landscape. Below is a trend analysis based on layoff data collected across the tech industry. Figure 1: Layoffs (in thousands) over time in tech industries Although the first AI research boom began in the 1980s, the current AI surge started in the late 2010s and gained significant momentum in late 2022 with the public release of OpenAI's ChatGPT. The COVID-19 pandemic further complicated the technological landscape. Initially, there was a hiring surge to meet the demands of a rapidly digitizing world. However, by 2023, the tech industry experienced significant layoffs, with over 200,000 jobs eliminated in the first quarter alone. This shift was attributed to factors such as economic downturns, reduced consumer demand, and the integration of AI technologies. Since then, as shown in Figure 1, layoffs have continued intermittently, driven by various factors including performance evaluations, budget constraints, and strategic restructuring. For instance, in 2025, companies like Microsoft announced plans to lay off up to 6,800 employees, accounting for less than 3% of its global workforce, as part of an initiative to streamline operations and reduce managerial layers. Between 2024 and early 2025, the tech industry experienced significant workforce reductions. In 2024 alone, approximately 150,000 tech employees were laid off across more than 525 companies, according to data from the US Bureau of Labor Statistics. The trend has continued into 2025, with over 22,000 layoffs reported so far this year, including a striking 16,084 job cuts in February alone, highlighting the ongoing volatility in the sector. It really makes me think — have all these layoffs contributed to the rise in the US unemployment rate? And has the number of job openings dropped too? I think it’s worth taking a closer look at these trends. Figure 2: Employment and unemployment counts in the US from JOLTS DB Figure 2 illustrates employment and unemployment trends across all industries in the United States. Interestingly, the data appear relatively stable over the past few years, which raises some important questions. If layoffs are increasing, where are those workers going? And what about recent graduates who are still struggling to land their first jobs? We’ve talked about the layoffs — now let’s explore where those affected are actually going. While this may not reflect every individual experience, here’s what the available online data reveals. After the Cuts Well, I wondered if the tech job openings have decreased as well? Figure 3: Job openings over the years in the US Even with all the news about layoffs, the tech job market isn’t exactly drying up. As of May 2025, there are still around 238,000 open tech positions across startups, unicorns, and big-name public companies. Just back in December 2024, more than 165,000 new tech roles were posted, bringing the total to over 434,000 active listings that month alone. And if we look at the bigger picture, the US Bureau of Labor Statistics expects an average of about 356,700 tech job openings each year from now through 2033. A lot of that is due to growth in the industry and the need to replace people leaving the workforce. So yes — while things are shifting, there’s still a strong demand for tech talent, especially for those keeping up with evolving skills. With so many open positions still out there, what’s causing the disconnect when it comes to actually finding a job? New Wardrobe for Tech Companies If those jobs are still out there, then it’s worth digging into the specific skills companies are actually hiring for. Recent data from LinkedIn reveals that job skill requirements have shifted by approximately 25% since 2015, and this pace of change is accelerating, with that number expected to double by 2027. In other words, companies are now looking for a broader and more updated set of skills than what may have worked for us over the past decade. Figure 4: Skill bucket The graph indicates that technical skills remain a top priority, with 59% of job postings emphasizing their importance. In contrast, soft skills appear to be a lower priority, mentioned in only 46% of listings, suggesting that companies are still placing greater value on technical expertise in their hiring criteria. Figure 5: AI skill requirement in the US Focusing specifically on the comparison between all tech jobs and those requiring AI skills, a clear trend emerges. As of 2025, around 19% to 25% of tech job postings now explicitly call for AI-related expertise — a noticeable jump from just a few years ago. This sharp rise reflects how deeply AI is becoming embedded across industries. In fact, nearly one in four new tech roles now list AI skills as a core requirement, more than doubling since 2022. Figure 6: Skill distribution in open jobs Python remains the most sought-after programming language in AI job postings, maintaining its top position from previous years. Additionally, skills in computer science, data analysis, and cloud platforms like Amazon Web Services have seen significant increases in demand. For instance, mentions of Amazon Web Services in job postings have surged by over 1,778% compared to data from 2012 to 2014 While the overall percentage of AI-specific job postings is still a small fraction of the total, the upward trend underscores the growing importance of AI proficiency in the modern workforce. Final Thought I recognize that this analysis is largely centered on the tech industry, and the impact of AI can look very different across other sectors. That said, I’d like to leave you with one final thought: technology will always evolve, and the real challenge is how quickly we can evolve with it before it starts to leave us behind. We’ve seen this play out before. In the early 2000s, when data volumes were manageable, we relied on database developers. But with the rise of IoT, the scale and complexity of data exploded, and we shifted toward data warehouse developers, skilled in tools like Hadoop and Spark. Fast forward to the 2010s and beyond, we’ve entered the era of AI and data engineers — those who can manage the scale, variety, and velocity of data that modern systems demand. We’ve adapted before — and we’ve done it well. But what makes this AI wave different is the pace. This time, we need to adapt faster than we ever have in the past.

By Niruta Talwekar

Domain-Centric Agile Modeling for Legacy Insurance Systems

Legacy insurance systems have accumulated decades of complexity in their codebases and business logic. This complexity is spread across batch jobs and shaped by regulation, rather than architecture. Directly applying modern Agile modeling to such a landscape often throws developers off track and into frustration. That is where Agile can work, but only when recentered around the realities of the domain. A domain-first perspective is captured by the fact that success in these environments cannot be achieved by providing screens and endpoints but by replicating the essence of how the business operates. Where Agile Fails Without Domain Awareness In many insurance transformation initiatives, every team begins by modeling the interface, which involves writing stories for forms, APIs, or dashboards. Legacy systems don't behave on the interface level, though. They act at the process level. The accurate units of business logic are actions such as policy renewal, claim escalation, underwriting override, etc. Unfortunately, those don't always show up in a UI. The team I worked with was a mid-sized insurer that automated policy life cycles, specifically renewals. Stories about frontend behavior started as a model for the first, but implementation quickly hit a wall. Pricing logic was clogged in a 15-year-old script. Multi-state compliance tables were used to conduct eligibility checks. Unraveling legacy dependencies was needed for every "simple" task. So we paused and started modeling from the domain behavior and from how the renewals were actually happening in the business. By letting us reorient, we could build more accurate, testable, maintainable functionality while still working in an iterative and Agile way, a necessity in intensely regulated environments like insurance domains and SaaS companies where business logic is tightly coupled with compliance. Why System Analysis Must Come First The shift wasn't accidental. No coding began until the required System Analysis was complete. We mapped out how renewals worked: who triggered them, what data was relevant, where decisions were made, etc. This analysis revealed inconsistencies in existing systems and knowledge gaps across teams. Without that upfront effort, the software we delivered would not have been of value. Such understanding is not a luxury in complex environments, such as the insurance industry. It's a precondition for success. Design Grounded in Business Reality Once we had a clear picture of the system's behavior, we started designing our modular functionality around it, ensuring that it truly met the business's needs. This wasn't just interface design work; it was more profound architectural Design work involving how information flowed, where the rules lived, and what would have to change for our modernization efforts to succeed. Instead of focusing on the business events themselves, premium recalculations, claim reopenings, and compliance flagging, we centered our design approach around these events and the language that everyone, from the product team to the QA engineer to the developer, could speak. This made planning sessions more effective and significantly streamlined the process of clarifying requirements during the sprint. Applying Agile Within This Structure Execution was always kept fully Agile. Our team employed Scrum to structure sprints, manage velocity, and deliver continuous support. The change was in determining the source of truth: instead of extracting stories from features, we used business scenarios as the source of truth. It enabled us to deliver software structured in a way that reflected the organization's workflow. The testing became more focused, acceptance criteria became more objective, and feedback loops to the stakeholders became shorter. Agile wasn't abandoned; it just got better because it came from the business, not just the product backlog. Beyond Insurance: Lessons from Retail and SaaS While this approach originated from insurance projects, it is applicable to any complex environment. One case involved working on a team with strong experience in Retail and Digital Product Domain, mainly in pricing systems across multiple brands. Region, season, inventory tier, and business rules all varied, and a traditional feature-first Agile approach repeatedly failed. It wasn't that we moved faster; it was that by switching to domain-centric modeling, our backlog became more stable, and our delivery velocity grew as the one without pointless rewriting of misunderstood features. For SaaS companies building for regulated markets, the same principles have been proven equally helpful. In this case, the challenge is not about legacy code at all but about ambiguous domain behavior. These identify how the software is used in real-world compliance workflows and help model against feature work so it remains aligned with business value. Conclusion Agile methodology provides structure and rhythm, but cannot replace understanding. Domain modeling offers the clarity to make Agile work in environments with decades of operational logic, such as those found in insurance, retail, and regulated SaaS. Moving beyond surface-level story writing is necessary for teams working on Software Development and Implementation of complex software systems in retail or regulated industries. Using actual behavior as the basis for modeling, backed by meaningful system analysis and sound design, Agile can become something far more significant than a process, something that is advantageous.

By Rachit Gupta

Designing Fault-Tolerant Messaging Workflows Using State Machine Architecture

Abstract As a leader of projects for the backend of a global messaging platform that maintains millions of users daily, I was also responsible for a couple of efforts intended to enhance the stability and failure tolerance of our backend services. We replaced essential sections of our system with the help of the state machine patterns, notably Stateful Workflows. The usage of this model led to the elimination of problems in the field of message delivery, visibility of the read receipt, and device sync, such as a mismatch of phone directories. The intention of this article is to let the reader know how to keep a messaging infrastructure highly available and adaptable by sharing the practicalities and trials one faces when bringing the said architectures into production. Introduction When dealing with distributed systems, you should always assume that failure will happen. In our messaging platform, it became very clear to us very quickly that unpredictable behavior was not something we should look at as a once-in-a-blue-moon occurrence, as it was in fact the standard state of affairs. Our infrastructure had to deal not only with network partitions and push notification delays but also with user device crashes, and our engineers did a great job in coping with such problems. Up to that time, instead of having service-level retry logic scattered all over, we selected a more systematic way of achieving the task, which involved the use of state machines. In the end, when we reimagined our business-critical workflows as entities with state, we realized that we had really found the way not only to automate a proper failure recovery process but also to do it in a predictable, observable, and consistent manner. This piece will focus on three main designs that we made use of — Stateful Workflows, Sagas, and Replicated State Machines — and how, through them, we not only built an impervious system but also let it respond to any failure scenario gracefully. Using Stateful Workflows for Message Delivery Message delivery is, without a doubt, the most crucial aspect of our system. In the beginning, we used a queue-based system without statefulness to send messages to devices. Unfortunately, we constantly faced unforeseen cases of the process stopping in the middle, which led to a situation where the user did not receive the message at all or received it with a significant delay. We tackled this problem by introducing the Stateful Workflow Pattern with the help of Temporal: Message Workflow States Send Message InitiatedMessage StoredPush Notification DispatchedDelivery ConfirmedRead Acknowledged Every transition from one state to another was done by events to which timers and retries were added. When a notification was not delivered (probably due to APNs/FCM complications), the system used an exponential backoff method to retry the request. In case the delivery confirmation failed to arrive in a timely manner, we made a note of the event, and if the customer wished, we might also trigger resolution mechanisms such as sending notifications by email. Each step was stored in the database's memory, which later enabled workflows to restart from the place where they stopped most recently, even after the system crashed or the node restarted. As a result, the number of messages lost was significantly decreased and the error states were visual in our monitoring applications. Implementing the Saga Pattern for Multi-Device Sync Another vital point is the importance of staying identical in the status of read messages on all the user devices. It means that if the user reads the message on one gadget, the change should be instant on all other gadgets. The above was implemented in a simple way, it was a Saga: Step 1: Mark the message as read on Device A.Step 2: Sync to cloud state.Step 3: Push read receipt to Devices B and C. Each of the steps was a local transaction. We would just component the corresponding reactions if one of them fails, thus no consistency would be lost. For example, if the failure is a sync to the cloud, then we would change the state backward and inform A of the problem, so that the result is no partial changes made. This very method lets us reach even consistency without the need for global locks or distributed transactions, which are both intricate and accident-prone. Using Replicated State Machines for Metadata Storage In order to keep the data, like the conversation state and preferences, in a consistent state, we have employed Replicated State Machines based on the Raft agreement protocol. It is this design that enabled us to: Appoint a leader to manage writesCopy the changes to all followersBring the state back by getting logs, if there is a crash This method was specifically beneficial for ensuring that we have a persistent chat indexing service and group membership management, where the state view was always correct. Comparative Analysis of Patterns I compared the most common state machine-based fault tolerance patterns to arrive at a solution that worked well for us. Aspect Replicated State Machine Stateful Workflow Saga Pattern Primary Goal Strong consistency & availability Long-running orchestration Distributed transaction coordination Consistency Model Strong (linearizable) Eventually consistent (recoverable) Eventually consistent Failure Recovery Re-execution from logs Resume from persisted state Trigger compensations Tooling Examples Raft (etcd, Consul), Paxos Temporal, AWS Step Functions Temporal, Camunda, Netflix Conductor Ideal For Consensus, leader election, config stores Multi-step business workflows Business processes with rollback needs Complexity High (due to consensus) Moderate High (compensating logic needed) Execution Style Synchronous (log replication) Asynchronous, event-driven Asynchronous, loosely coupled Results and Benefits Implementing state machine patterns brought the following improvements that could be measured: Message delivery retries fell by 60%.Read receipt sync issues were cut down by 45%.Service crashes recovery time reached under 200ms.Incident resolution time thus got decreased by observability. Furthermore, we managed to come up with internal tools such as dashboards obtained through the visualization workflow state per message during on-call incidents. Conclusion In a messaging system, reliability is not an add-on — it's a must. The users assume that their messages are delivered, read, and synchronized at the same moment. Therefore, using state machines to model essential workflows, we developed a fault-tolerant system that could gracefully recover from dangers. The decomposition of Stateful Workflows, Sagas, and Replicated State Machines gave us the means to regard faults as equal entities in our architecture. Although the implementation was a bit of a hassle, the benefits of robustness, clarity, and operational efficiency were significant. These patterns are now the foundation of how we are thinking of building our services throughout the organization in a strong manner.

By Pankaj Taneja

The End of “Good Enough Agile”

TL; DR: The End of “Good Enough Agile” “Good Enough Agile” is ending as AI automates mere ceremonial tasks and Product Operating Models demand outcome-focused teams. Agile professionals must evolve from process facilitators to strategic product thinkers or risk obsolescence as organizations adopt AI-native approaches that embody Agile values without ritual overhead. The Perfect Storm Coming After Good Enough Agile For two decades, many of us have participated in, or at least witnessed, a prolonged performance of “Agile-as-theater.” Now, the curtain is falling. Mechanical Scrum, stand-ups — or Daily Scrum, if you prefer that term — without tangible purpose, estimation rituals that pretend to forecast the future, Jira-as-performance-art; we’ve normalized Agile as a checklist. Useful, perhaps, if you blinked hard enough and never dared ask about the return on investment. That era is ending, not with a dramatic bang, but with a slow, irrevocable drift toward irrelevance for those who don’t adapt. What’s forcing this change? Two converging forces that aren’t just disruptive but existential threats to “Good Enough Agile:” Artificial intelligence and the Product Operating Model. Let’s be brutally honest: If your primary Agile practice revolves around facilitating meetings, meticulously documenting progress, and shepherding tickets from “To Do” to “Done,” you are now officially redundant. AI can, and already does, perform these tasks. It’s faster and cheaper and doesn’t need a “Servant Leader” to guide a Retrospective summary and its follow-up communication. Mechanical Agile: Already Obsolete The uncomfortable truth is that most Agile implementations never graduated beyond the delivery phase. Strategy? That was deemed someone else’s problem. Discovery? Often skipped, outsourced, or diluted into a Product Backlog of unvalidated ideas. Empowerment remained a popular keynote topic, not an operational reality. Agile teams became efficient delivery machines: tactical, often fast, but fundamentally disconnected from actual business and customer outcomes. That’s not agility; that’s a feature factory wearing a lanyard that says “Scrum.” The 2020 Scrum Guide states, “The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research, and development…”. Yet, in practice, how many Scrum Teams are truly empowered to this extent? Most are boxed into building what someone else, somewhere else, decided. And AI is going to eat that box. Consider what generative AI achieves today: Summarizes Sprint Reviews and Retrospectives,Clusters customer feedback into actionable themes,Highlights potential blockers by scanning Jira, Slack, and Confluence,Prepares release notes and offers data-informed team improvement suggestions. If your role primarily focuses on these facilitation, coordination, or status-tracking aspects, you’re no longer competing with other humans. You’re competing with code and tokens. AI doesn’t need psychological safety or emotional labor. It needs inputs and patterns. It doesn’t coach, it completes. Product Operating Models: The New Baseline for Value Creation If AI relentlessly attacks the how of mechanical Agile, Product Operating Models fundamentally redefine the why and what. The Product Operating Model, as championed by Marty Cagan, isn’t just a new practice; it’s a shift in how effective companies build, deliver, and iterate on value. It demands teams solve real customer problems aligned with tangible business outcomes, not just dutifully executing on stakeholder wish lists or pre-defined feature roadmaps. This model requires: Empowered teams assigned meaningful problems to solve, not just features to build. They are accountable for outcomes.Decision-making that spans product strategy, discovery, and delivery, with teams deeply involved in determining what is valuable, usable, feasible, and viable.A culture of trust over control, principles over rigid processes, innovation over mere predictability, and learning over fear of failure. It’s not that the Product Model dismisses Agile principles. Instead, it subsumes them. Think of it as an evolved organism that has internalized Agile’s most useful DNA, like continuous delivery and cross-functional collaboration, and discarded the empty rituals. This shift exposes how shallow many Agile adoptions are. Recent survey data highlights that 12% identify a lack of product vision as leading to “Feature Factory” waste, while another 33% pointed to a leadership gap, not necessarily micromanagement, but a disconnect between professing Agile values and actually empowering teams to achieve outcomes. Poor Agile implementation was cited by 10%, showing that process obsession often hurts more than it helps, and 12% highlighted cultural resistance, where psychological safety and a learning environment are absent. Old Agile vs. New Reality Here’s what the paradigm shift demands: Stand-ups vs. Outcomes: Are you syncing or solving?Estimates vs. Telemetry: Are you gambling with guesses or learning in real time?Belief vs. Evidence: Does your Product Backlog reflect strategy — or stakeholder fantasy?Mechanical Rituals vs. Market Results: Is your Agile a safety blanket or a value engine? This is not a theoretical debate. It’s a fork in the road. The Agile Industrial Complex Is on Notice Agile didn’t die because it wasn’t valuable. It’s struggling because when agility became a product, it lost its edge. The monetization of the Agile Manifesto. The transformation theater. The armies of consultants selling templates for self-organization. The playbook peddlers. Organizations wanted change but settled for frameworks instead. They got stand-ups instead of strategy. They got rituals instead of results. The Agile industrial complex mistook adoption for impact. It sold belief over evidence. And the reckoning is here. “But Our Agile Transformation Is Working!” I know what you’re thinking. Perhaps your teams genuinely feel empowered. Maybe your Retrospectives drive real change. Your Product Owner might truly represent customer needs rather than stakeholder demands. Congratulations! If that’s your reality, you’re already practicing what I’m advocating for. You’ve transcended mechanical Agile and built something that actually works. You’re not the target of this critique; you’re proof that it’s possible. But here’s the uncomfortable question: Are you sure you’re not confusing efficient delivery with effective outcomes? Many teams that feel “empowered” are still fundamentally executing someone else’s strategy, with more autonomy in building features. The test is simple: Can your team pivot the entire product direction based on what you’re learning? Or do you need permission? Acknowledging the Loss If you’re feeling defensive or unsettled right now, that’s completely understandable. Many of us have invested years mastering practices that felt meaningful and valuable. We’ve built our professional identities around frameworks that promise humanizing work and unleashing creativity. The events that once felt revolutionary now risk becoming ritual. The frameworks that once liberated teams have calcified into the process. This isn’t your failure; it’s a natural evolution that happens to every successful practice. Letting go of what once worked doesn’t diminish its past value or your expertise in applying it. It takes courage to evolve beyond what made you successful. (And I do include myself here, believe me.) What Happens Next: The Rise of Post-Agile Organizations Product-led organizations that fully embrace AI and outcome-driven Product Models will likely skip past traditional, ceremonial Agile entirely. They will: Use real-time telemetry (or data) to understand what users do, not just guess what they might wantLeverage AI to generate tests, documentation, and even first-pass UIs in minutes, not SprintsFocus on learning velocity — how quickly they can validate hypotheses and adapt, not just delivery velocityReallocate human intellect to the highest-leverage work: deep customer insight, ethical considerations, strategic judgment, and genuine invention These organizations won’t be hiring legions of Agile Coaches. They’ll seek Product Strategists and Product Coaches who understand the full value creation lifecycle. They won’t need Scrum Masters to run meetings. They’ll have empowered, cross-functional teams with live telemetry dashboards and a clear mandate to ship value, not just track velocity. And they will outcompete traditional organizations decisively. A Vision of What’s Possible Imagine working on a team where AI handles the administrative overhead, where real-time data tells you immediately if you’re solving the right problem, and where psychological safety comes from shared accountability for outcomes rather than adherence to process. Picture teams that spend their energy on deep customer research, ethical considerations, and creative problem-solving rather than estimation poker and Sprint Planning. Envision organizations where “empowerment” isn’t a buzzword but an operational reality: Teams that can pivot strategies based on evidence, not just tactics based on backlog priorities. This isn’t about losing the human element of work. It’s about elevating it. When AI handles coordination and data analysis, humans become free to do what we do best: Understand nuanced problems, navigate complex stakeholder dynamics, and create innovative solutions. This future isn’t dystopian; it’s energizing. But only for those willing to evolve toward it. Scrum Can Survive — By Going Back to Its Roots and Becoming Invisible There’s still a place for Scrum, but only if it’s stripped back to its original, minimalist intent: a lightweight framework enabling a small, autonomous team to inspect, adapt, and solve complex problems while delivering valuable increments. It should be the near-invisible scaffolding that supports the team’s functionality, not the focus of their work. The second you start optimizing your Scrum process instead of your product and its outcomes, you’ve already lost the plot. How to Stay Relevant: A Survival Guide This article isn’t about fear-mongering; it’s about a clear-eyed assessment of a fundamental shift. (And I have been struggling to formulate it for months.) If you’re sensing this transition is real and inevitable, here’s how to navigate it: 1. Become Radically Product-Literate Stop facilitating. Start understanding. Learn product strategy. Immerse in discovery. Study customer behavior. Know how the business makes money and how your work contributes to it. If AI can do a significant part of your current job, immediately pivot your development towards uniquely human strengths: Coaching for critical thinking, systems thinking, complex problem framing, and outcome-oriented product strategy. 2. Shift from Output to Outcome Obsession Shipping fast is not valuable in and of itself. Don’t be satisfied with being a world-class delivery facilitator. Insist on understanding and contributing to why anything is being built. Push for access to the strategic context and the discovery process; your value multiplies when you connect delivery excellence to strategic intent. 3. Partner with AI, Don’t Compete AI is not your enemy. It’s your amplifier. Automate coordination. Use LLMs for sense-making. Audit your rituals mercilessly: If a meeting or artifact doesn’t directly drive a measurable, valuable outcome, kill it. Free yourself to do the one thing AI can’t: Frame the right problems and align humans to solve them. Conclusion: This Isn’t a Fad. It’s Evolution. We are not just weathering the storm but witnessing evolution in real-time. You are living through a paradigm shift defining the next two decades of product development. “Agile” isn’t “broken” simply because of poor adoption or choosing the “wrong” framework. It’s transforming because the world has changed technologically, strategically, and economically, and our practices must also change. There’s a delicious irony here: A practice built on rapid learning and continuous adaptation has become remarkably bad at eating its own dog food. We’ve spent years teaching organizations to inspect, adapt, and embrace change over following a plan. Yet, when faced with the most significant technological and strategic shifts in decades, much of the Agile community has chosen to double down on familiar practices rather than inspect and adapt them. The very principles we’ve evangelized, I refer to empiricism, experimentation, and pivoting based on evidence, should have prepared us for this moment. Instead, we’ve often responded like any other established industry: Defending the status quo, questioning the data, and hoping the disruption will somehow pass us by. We’re entering an era of AI-native, outcome-obsessed, telemetry-driven organizations. They don’t need Agile frameworks. They embody the values. The fundamental question is no longer about doing Agile right but being effective in a world increasingly shaped by intelligent automation and a relentless focus on demonstrable product outcomes. Are you ready to help shape what comes next? The future belongs to those who can bridge the gap between Agile’s foundational values and tomorrow’s technological reality. The question isn’t whether change is coming — it’s whether you’ll lead it or be swept along. What will you choose to build?

By Stefan Wolpers

CORE

Advancing Your Software Engineering Career in 2025

The Key Industry Trends You’ve probably heard of "The Great Flattening." In 2024, companies like Amazon, Google, and Meta started cutting middle management to make things more efficient. As a manager, I’ve felt this shift firsthand. Suddenly, there are fewer layers, and while it’s streamlined decision-making, it’s also changed how we think about career growth. But here’s the good news: for engineers, this doesn’t directly impact our day-to-day work. We’re still building, innovating, and solving problems. Then there’s GenAI. I was skeptical initially when I first heard tech leaders like Mark Zuckerberg predict that AI could replace mid-level engineers by 2025 or when Google CEO mentioned that 25% of Google’s new code is already AI-generated but as of now, you may have also experienced this first hand on what Gen AI coding agents can do. As per this article from CIO, AI coding agents will take over the world by 2027. So how do you thrive in this world and advance your career? Here is some of my advice which is equally applicable in the normal or challenging times. Strategic Approaches for Career Advancement It’s more than coding Although determining exact percentage impact of the time you spend coding is a bit tricky, it typically accounts for 20-40% of the total effort. The rest of software development involves critical activities like planning, stakeholder collaboration, system design, deployment, and monitoring. Senior engineers can focus heavily on architecture and strategy, which can significantly outweigh raw coding in impact. Often senior engineers get less time to code because they are more focused on the larger more strategic initiatives like implementing complex systems, ensuring their scalability, reliability and efficiency, etc. They translate business objectives into technical strategies. So although coding is important, there is a lot more to growing your career than just coding and you need to focus on those areas. My advice -- use Gen AI to its full potential to free up your time from solely coding, and focus more on other areas which we will talk more of. Develop excellence and deliver consistently Your focus should be to make excellent software. Develop deep expertise in your domain and deliver results on time. Doing so establishes trust with your manager and in time, you become the go-to-person for their critical projects. Results matter, and once you start delivering consistently, then success, rewards and opportunities will follow. We all need people on whom we can rely on even in the toughest of times and know that they will get the job done. You become part of their inner circle and your manager raves about you everywhere. Duplicate yourself People often make themselves critical by keeping control of certain important parts of the project. This has an absolutely opposite effect. Being the only person who can deliver on sonething is a drag on your career. The best strategy is figure out how you can duplicate yourself. In other words, teach someone else to do what you do so that you can move on to do work of high value and more overall importance to the project. This is how you scale yourself in real life. Now, your manager not only can trust that you are their go-to, he or she is seeing you as a multiplier who is raising the entire team with them. Be receptive to feedback Being open to feedback is a game-changer for growth. If someone is criticizing your idea, do not be defensive! Instead, use this as a golden opportunity to capitalize on that feedback. Self-reflect or talk to other people to see if if they notice the same behavior. You should also proactively seek feedback from your peers, managers, and stakeholders to sharpen your skills and align with team goals. Know what leadership wants and what your customer needs You don’t need to understand the game or learn how to manipulate management. You just need to understand what your leadership prioritizes—whether it’s scalability, cost efficiency, or innovation—and what your customers truly need, like intuitive features or reliability. You may not directly be in meetings with senior leadership but you can often gain access to the same documents like monthly and quarterly business reviews, roadmap planning, long-range vision docs, and more. This will give you a great sense of what your leadership prioritizes. To understand what your customer needs, you are blessed if you can talk to your customer directly and shadow them. You can ask what they love about the product, what can improve, and if they had a magic wand then what is one thing they wish your product could do. If you don’t have this opportunity, you can learn that indirectly by reviewing your backlog created by customers, frequently repeated bugs, reading reviews, revisiting past surveys, etc. By syncing your work with these goals, you'll be able to deliver impact that resonates with both your management team as well as customers and earns you recognition. You'll also begin seeing how your work connects with the strategic direction of your organization. Finslly, you'll will have a very good idea on why certain projects are being prioritized. Think at next level Now that you are thinking strategically rather than tactically, start looking at what people operating at an organizational level above you do. Set up a meeting with someone north of you in the org chart and talk about what their day to day looks like and what suggestions they have for you as you work to advance. You can ask them what you can do to help and help them out. By doing this, you are creating a sponsor who will actively invest their time to ensure your career success. Follow through and close the loop This is probably the most underrated skill. But it's the most important. Never drop the ball! If you have made a commitment, always follow through and make sure to close the loop on that conversation or commitment. If priorities change and you can’t meet the commitment, follow up and let the stakeholders know about the shift in priorities. And just in case, you did drop something, follow up again as soon as possible and apologize for dropping the ball. Conclusion While the tech industry is going through a seismic shift, it also offers substantial opportunities for professional growth and innovation for software engineers. By adopting strategic approaches such as leveraging GenAI to focus beyond coding, developing excellence in software delivery, duplicating oneself to scale impact, being receptive to feedback, aligning with leadership and customer needs, thinking strategically, and ensuring follow-through on commitments, engineers can navigate this dynamic landscape effectively. By following these steps, you can not only thrive in your career but will also become a great asset for your manager, leadership and team.

By Gaurav Mishra