Mohamed Fouad

After good amount of time practicing and preaching TDD (Test Driven Development), now it feels insecure to write the tests after the function. If the tests pass, does it mean my function is correct or my test is wrong?

11

3 Comments

A real simple case of how TDD from the inside-out can lead to poor design... I was working on a simple function to nest one data structure inside another based on parent and child relationships. I created the following simple test, and got AI to pass it: > parents = [{'id': id, 'name': 'mother'}, {'id': 2, 'name': 'father'}] > children = [{'name': 'child', 'parent_id': id}] > assert nest_children(parents, children) == [{'id': id, 'name': 'mother', 'children': [{'name': 'child', 'parent_id': id}]}, {'id': 2, 'name': 'father'}] GenAI did a good enough job. It created a list of parents by id: > parent_lookup = {parent['id']: parent for parent in parents} And then looped the children by looking up the parent in the list. > parent_id = child['parent_id'] It worked so in the spirit of red, green, refactor I began to refactor. First thing I decided was that the function knew too much about the data structure. Really this should be passed in. To provide maximum control I decided to provide a lambda. I refactored in steps (extract variable, variable to parameter etc.) Now I ended up with a function which looked like this: nest_children(parents, children, lambda p: p['id'], lambda c: c['parent_id']) Test passed. Job done. Not quite so fast! Look what just happened. The signature reflects the algorithm. Do you see? I'm passing two lambdas because that's how the algorithm works. This is what happens when we drive design based on implementation. I needed to stop and think again what my test should look like from a client perspective. And then make the test pass with the right algorithm. Once I thought about it, a much neater and more idiomatic function would follow the style of map: > nest_children(myfunc, parents, children) or: > nest_children(lambda p, c: p['id'] == c['parent-id'], parents, children) Now I have to change my algorithm (or GenAI does) to pass the test. See the difference testing from the outside makes to your design?

1

5 Comments

Observation: 9/10 SWE's quit at “reading the docs”. Cut through the BS with this easy trick: Take action and build. Writing code is 100x easier than the docs make it sound. “Reading the docs” gave me crazy imposter syndrome: -Git -WPF -Kafka -OAuth -Angular -GraphQL -RabbitMQ -Kubernetes In ALL cases, I conquered my fears by building. Except for WPF. I gave up on that. And Kafka, that's for another day. Forcing yourself to build/code/deploy melts analysis paralysis. Then you'll say "oh that was pretty easy". Trust me, we aren't building rockets. Practice AND Study build true mastery.

22

1 Comment

In my Kotlin Multiplatform journey, I needed to integrate a 3rd party Swift library with my Kotlin code. So, essentially, learn how to call non-stdlib Swift. JetBrains really did a great job with interop support! And a hell of a job documenting all that. But interop with pure Swift libraries is not yet supported, only if ObjC is at play. Okay, this is 2024, there always is another way. So I did Claude a shot. Explained in detail the context, why, and what I want to achieve. As well as the initial "how". And it did respond! Said that yeah, my task was a challenge, but it has my back. And supplied a well-crafted plan and architecture of the app, with a very nice diagram explaining what exactly it suggests. Remember underpants gnomes and their plan, from the South Park show?

1

I’m back with a friendly reminder that TDD is overrated in mobile development. 👋 According to Alex Chiou: ↳ The instagram app got to 1 billon users with less than 5% automated test coverage on its mobile apps. ↳ They did that by focusing on a culture of quality, not bureaucracy. ↳ Engineers used the app themselves so they knew the pain if they wrote bad code. I know TDD can be great and very powerful in a lot of situations. But great apps can still be built without it. And when you’re working in a fast paced environment, especially a startup, you have to keep pushing those features. There’s very little time to go through the whole TDD cycle. What do you think? Share your opinion and repost for others. — If you’re an app founder who’s looking to scale up, DM me and let’s partner up! #TDD #AutomatedTests #Mobileapps #Instagram #Testing #iOS #android

74

31 Comments

Returning to Java from Kotlin has me thinking again about nulls and null-safety. Kotlin has softened me somewhat on the subject of nulls, because its handling of them is safe and elegant: declaring a type as T? is more or less equivalent to declaring it as Maybe T in Haskell, and null is just a compact representation of None in that case. The compiler will simply reject anything that tries to pass null, or the unchecked value of a variable of nullable type, to a non-nullable receiver. It's one of the two things about the language I'm really going to miss (the other being the Ruby-like block syntax). After a phase of thinking Optional<T> should be used to do the same thing in Java, I'm actually swinging back more towards annotating optional fields and parameters as @Nullable, and relying on tooling (the IDE, build-time linting) to enforce Kotlin-like null-discipline. But there's a skeleton in the closet: older (pre-record-type) Java often has a lot of POJOs with default no-argument constructors lying around. You construct one, everything's null, you set fields one by one with the setters. It's much harder to impose null-discipline of any kind in this scenario. People depend on this behaviour, too - they create test value objects by newing up instances of POJOs and setting only the fields the code under test is interested in, and everything works. You can say "you should make it impossible to construct an object in an invalid state" all you like, but you're going to break all those tests if you actually take the ability to partially populate a value type away from them. Lombok doesn't help, either - there's no way to compile-time check that all the mandatory fields have been added to a builder before calling build(). And even with record types, the ability to use builders to supply field values by name, rather than relying on their order in the constructor signature, is going to be hard to take away from people working with value types with a dozen or more fields. Java is just an ever-burning tire fire around these issues, and always has been, and it's a major reason why "legacy" code tends to suck so much. At the moment the best I think I can do is try to promote a general pattern: if you can't ensure correctness on construction, validate correctness immediately after construction (and prevent illegal mutation after that). At least then you can eliminate ad hoc null checks downstream of validation, and be clear about when missing values are actually to be expected.

84

34 Comments

🚀 **Building Scalable Enterprise Applications in C#? Let’s Talk Best Practices!** 🧑‍💻 👩‍💼 Imagine this: Your C# application is handling 10 users effortlessly, but can it handle 10,000? 100,000? Scalability is the superpower that ensures your enterprise applications grow with your business — without breaking a sweat. Here’s what makes a difference: ✅ **Asynchronous Programming** – Optimize performance and reduce bottlenecks with async/await. ✅ **Dependency Injection (DI)** – Keep code clean, testable, and decoupled to handle future complexities like a pro. ✅ **Caching Strategies** – Slash response times by implementing efficient memory or distributed caching solutions. ✅ **Microservices Architecture** – Scale services independently instead of rebuilding the monolith. ✅ **Profiling & Optimization** – Regularly review your code for hotspots and optimize for long-term efficiency. 💡 By mastering these practices, you’ll equip your applications to thrive under high demand while delivering smooth user experiences. 📣 *Your turn*: Have you implemented these strategies in your own work? What challenges did you overcome when scaling C# applications? Share your insights or drop your questions in the comments! Let’s collaborate and grow together. #CSharp #EnterpriseDevelopment #Scalability #CodingBestPractices #moa7amed #moa7amed_com

1

Embedded developers with niche skills are like gold dust. If you find one, don’t hesitate... hire them quickly. I see over and over that these specialists are often snapped up by companies that understand their value. That means your hiring process needs to be not just fast, but also enticing. Competitive salaries, interesting projects, and a clear path for career growth are essential if you want to attract and retain this top talent. Speed and flexibility in hiring can make all the difference 🙏 The companies that adapt their recruitment strategies to move quickly are the ones that will come out on top.

3

🌍 **Diversity: The Secret Ingredient for Outstanding Software Teams** 🌟 Have you ever wondered why some software teams thrive while others struggle—despite having similar resources? One often-overlooked factor is **cross-cultural collaboration**. When done right, it’s not just about reducing friction—it’s about sparking innovation. In my experience building software teams across borders, here’s what stands out: ✅ A mix of cultural perspectives leads to better problem-solving and creativity. ✅ High-performing teams don’t eliminate differences; they harness them through empathy, clear communication, and shared goals. ✅ Inclusive environments create a stronger sense of connection, ownership, and motivation. Success lies in understanding **HOW** to bridge cultural gaps and foster collaboration. From defining shared values to adapting feedback styles, every step matters. (Spoiler: It's not just about team-building exercises!) 💡 Are you leading—or dreaming of building—a global software team? Let’s share insights! 🔁 What challenges have you faced working in cross-cultural teams? 💬 How do you approach collaboration with colleagues from different cultures? Drop your thoughts below; let’s learn from each other! 🚀 #SoftwareTeams #Leadership #DiversityInTech #CrossCulturalCollaboration #Innovation #TechLeaders #moa7amed #moa7amed_com

1

Most companies struggle to hire killer senior engineers. So what should the ideal interview process for finding this talent look like? Whenever I advise early-stage tech startups, I tell them to include the following questions and steps in their interview process for senior engineers: 1. Have them interact with stakeholders in the company You need proof that a senior engineer can work well with stakeholders. They must be able to delegate and empower engineers to make various decisions. Any engineer who can communicate well and work with stakeholders is a solid hire. 2. Have them speak to a designer or product manager Senior engineers will be speaking to designers and product managers frequently. If you can get a designer or product manager involved in the interview process, you want your colleague to assess whether that engineer is someone they can work with. Some questions they can think about include: - Can I have a conversation about what’s valuable to the business with this engineer? - Can this engineer communicate well? Do they complicate things? Do they oversimplify? - How do they react if there’s an ask from design or marketing? What is their thought process? 3. Figure out their attitude toward junior engineers A senior engineer’s attitude toward junior engineers is a good bellwether of their attitude toward communication and documentation. One sign of a poor senior engineer is someone who can’t explain their work — or doesn’t feel like they have to. They feel no need to document what they’re doing and they assume everyone around them, like their junior engineers, will just get it. If you ask an engineer, “How do you communicate your work to others?”, and they say “I don’t really see the value in that,” that’s not someone you want to hire. It’s incredibly important to an early-stage organization to prioritize clear documentation and communication. I’ve advised too many companies that did this too late and had to waste time parsing the code of engineers who didn’t bother to document anything. Any startup can avoid this fate by hiring good senior engineers who explain their work every step of the way. 4. Figure out how they plan for the future Developing a good product isn’t just about good design or code. It’s also about future-proofing your code. I think a big thing about seniority is balancing making good decisions quickly while not shooting yourself in the foot. It means seeing beyond the future and recognizing the implications of their decisions, such as: - Is this code future-proofed or not? Am I creating technical debt? - Has this particular solution created any new problems for the team? Who knows how to solve them? Am I the only one who knows? You especially don’t want your company to deal with technical problems that can only be solved and documented by one person on the team. That can lead to a crisis if that person ends up leaving. cont. 👇

3

1 Comment

🚀 Unlock Flexible Design with TDD! 🎨🔧 Designing is hard. But what's harder? Changing designs after they're live. 😫 Meet Test-Driven Development (TDD)! 🛠️✨ TDD is a way developers write tests before coding. It offers lessons for design: 🔍 Break It Down: TDD turns big ideas into small, easy parts. Your designs become simpler. ⚡ Catch Issues Early: Find and fix problems at the start. Avoid bigger troubles later. 📚 Better Documentation: Understand more and create clearer guides for your team. How does TDD boost your design? Like TDD keeps developers focused on user needs, apply the same to design: ✨ User Stories: Write stories and map the user journey. Your design will grow with users' needs. ✨ Flexible Framework: Build with foresight. Your design stays agile and ready for change. Take a tip from TDD: Test your designs before building them. Your users and team will thank you! 🙌 🔄 Found this helpful? Share it, and let's improve the design together! #DesignThinking #TDD #UserExperience #FlexibleDesign #Innovation #UXDesign #ProductDesign

6

1 Comment

One of the reasons I love REPLs is that they tighten the feedback loop. What do you all use to tighten feedback loops?

3

10 Comments

What really pisses me off about the way TDD is usually taught / demonstrated is how the REFACTOR part is simultaneously downplayed as "just refactoring" and yet at the same time it magically does all of the design for you. In my experience the developer still has to do all of the design, and that's far from being a beginner level skill. Conversely, every refactoring move has an inverse, and so refactoring by itself is agnostic to code / design quality. In most TDD demonstrations I've seen, the exercise is sufficiently small that the resulting design is either trivial, or was worked out beforehand, or is terrible (bowling scores kata, much?). TDD is just as difficult as good software design. Rant over (for today) 😎

34

11 Comments

🚀 New Video : What Do Software Engineers ACTUALLY Do? 💻 Curious about what software engineers really do? In this video, I cover: 🔧 Coding & Building Apps: How we bring software to life! 🧠 Problem Solving: Tackling technical challenges every day. 🤝 Teamwork: Collaborating with designers, developers, and managers. 📈 Continuous Learning: Staying updated with new tools and technologies. If you're thinking about a career in tech, this video gives you a real behind-the-scenes look! 🔗 Link is in first comment 👇 #SoftwareEngineer #TechCareers #Coding #DayInTheLife #CareerInTech

3

4 Comments

Incorrect Generalizations with Amitai: einfach = simple vielfach = complicated nullfach = impossible

9

1 Comment

🚀 **Why DevOps is the Superpower Your Team Needs in Modern Software Development** Imagine delivering high-quality software faster, with fewer bugs, and happy teams that actually enjoy collaborating. That’s not a dream—it’s the reality DevOps brings to the table. By bridging the gap between development and operations, DevOps enables: ✨ **Faster delivery**: Automate repetitive tasks and streamline workflows. ✨ **Higher quality**: Test continuously to catch issues early. ✨ **Team alignment**: Improve collaboration by breaking silos. ✨ **Scalability**: Handle growth seamlessly with cloud and CI/CD tools. DevOps isn’t just a practice—it’s a mindset that changes the way software gets built and delivered in today’s fast-paced tech world. Want to empower your team to innovate faster and smarter? Start by embracing DevOps. #DevOps #SoftwareDevelopment #TechInnovation #Automation #CI_CD #Agile #moa7amed #Kaggle #Teamwork

1