Software Engineering

Complete guide to understanding system design interviews, what interviewers expect, and how to prepare effectively for distributed systems and scalability questions.

In software engineering, your output - the code that you write, is only as good as what you have learned, experienced and understood from your conversations with the client, which is the input. This is true when working with Large Language Models (LLMs). If you use GenAI tools to complement your expertise in software engineering, then here are some strategies you can use to move beyond basic code generation and into collaborative development, or better pair programming with AI. ...

Warning ...

In my current role, I manage a very special team of quality engineers who are responsible for setting standards and best practices for quality assurance across the entire organisation and is also responsible for developing any necessary tooling or frameworks that might help product teams reduce toil. This is not a new problem and hence I was looking for inspiration and lessons to learn from other organisations who have embedded quality at the heart of their software development process. I came across this presentation by two Quality Specialists who also happen to be Atlassian partners. Please go ahead and watch it if you haven’t already. ...

When building applications, it is fundamental to think about design first. This process of designing first helps visualize some of the key areas that you are going to tackle. How are the different elements or components going to interact with one another? What are the various components going to be? What are the responsibilities of each of these components? Software Engineering is a pretty young field, compared to other engineering domains. And over the last 60 years or so, has made tremendous amount of progress. This has led to the rise of several different blueprints for solving common problems, often called design patterns or architectural patterns. These are great tools to use when developing your solution, provided you understand what they solve and when best to use them. ...

“The Invisible Man.” by Chaotic Good01 is licensed with CC BY-NC-SA 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/2.0/ Keeping people informed Early in my career, I thought writing software is all about the outcome. Delivering something that works. I thought it didn’t matter how it was done. At the end of the sprint if you didn’t have a deliverable, it was a problem. This was true in companies which adopt a waterfall model of development. ...

The problem A lot of software engineers get into the industry and often end up starting to write code soon after they read the requirements’ specification. Sounds familiar? You might have done it too. Hard to admit? Can be. We are humans, after all. Jumping right into the coding process might be a great idea for a simple coding challenge, where the objective is to solve a problem in as little time as possible, with potentially very few lines of code. You just have that very specific goal. You don’t have worry about future enhancements for that solution, nor do you have to think about maintainability of that solution. Once solved, the code might have to run through a set of tests and pass the criteria of the question. Fantastic! And you might even get selected for the next round of interviews! Great! So why think about design when you start working on a real solution? ...

LINQ stands for Language Integrated Query Language. It was a feature introduced along with Visual Studio 2008 that extends the querying capabilities of C# for any sort of data source. Generally LINQ is used to query data sources like SQL Server Databases and XML files. I use it to query databases. I’m not going to explain everything about LINQ here. I’m going to just talk about some very basic details. ...

As you might have noticed from my recent posts, I’ve just recently jumped from one platform to another. And my current project is a bit of a legacy thing. A lot of people worked on it previously and those who did weren’t necessarily experts in the technology that they used when they initially developed it. They did a lot of hacky things, to get things going. But such hacks are good for getting a product moving, but not really good for maintaining them. And now that I’m having to implement changes to them, I realized how hard they have made this for me. ...

I think as programmers you should read and understand this: http://martinfowler.com/ieeeSoftware/explicit.pdf From the expert in OOAD and related stuff - Martin Fowler.