Stanley Nii Armah(Junior)’s Post

Code is secondary. Business value is first. No one is going to approach you and remark, "Wow, you did a great job writing that one-liner! It's amazing!" Instead, depending on how fortunate you are, they will remark something like, "Users are happy with the feature that you wrote," or, "Your code took down the whole website." It might surprise you to learn that a software engineer's main responsibility is not producing code, but rather adding value through the use of developed software. Code is only a tool to help you get there. Software -> Code -> Value. Your work must address a need in the world; it must be a tool that people will use, an automated process that lowers expenses, or something that people will pay for with their time, money, or attention.

Technical debt, representing the implied cost of additional work caused by choosing expedient but suboptimal solutions in software development, is a concept that transcends just writing code. It encapsulates a profound understanding of technology stacks, languages, algorithms, and design principles. The impact of technical debt is far-reaching, with studies showing that up to 40% of development time can be wasted due to it.   Understand by SciTools provides a comprehensive solution to navigate technical debt. It offers features that aid in understanding complex codebases, evaluating code metrics, and identifying potential issues. This allows developers to maintain higher code quality and reduce technical debt. Ignoring technical debt can lead to poorly optimised code, scalability issues, and security vulnerabilities.   In a world where understanding technical debt and code metrics is increasingly important, Understand is a powerful static analysis tool, that helps manage technical debt, optimise code structures, and find code defects as the code is written. Sign up for a free trial now and elevate your software development skills to the next level: www.emenda.com/trial   #TechnicalDebt #SoftwareDevelopment #SciTools #StaticAnalysis #BugHunter

There is a recurrent debate among software developers: should functions be small and favor modularity, or should they be larger to favor readability? This is a false choice. It's not about code. It's about tools. Indeed, if you only consider plain code editors, then it can be an issue. But if you use an editor that allows you to expand arbitrary nesting levels, the issue disappears. Tools are essential in software development. Many current assumptions about software engineering become irrelevant once you add tools into the equation, especially if you consider the idea of custom tools. #MoldableDevelopment

Depite having watched software development tools get better and better over the last 40 years, I cannot agree with Tudor Girba on this. Great tools don't make it easy to maintain bad code. Yes, they make it EASIER, but the easiest way to make code easy to maintain is to write it that way, and that means taking account of the characteristics set out in ISO/IEC 25010. Simply put: Maintainability = Analyzability + Modifiabilty + Testability + Modularity + Reusability

Anyone familiar with enterprise software development knows about Technical debt. As #nocode enters this world, it's tempting to think that this is not a factor for us. Not true! In fact, I'd argue technical debt is being built up faster in projects using tools like Bubble for both front and backend. The unstructured nature of the platform, ability to build things using multiple different patterns and lack of documentation that usually accompanies this approach, means that code quickly becomes unwieldly, complex, hard to trace and slow to extend. For those new to this concept, here's a primer.. Technical debt refers to the implied cost of additional rework caused by choosing an easy or expedient solution over a better approach that would take longer. It's a metaphor borrowed from the financial concept of debt, where you incur interest by not paying for something right away. In software development, technology debt can accumulate when developers take shortcuts, use quick workarounds, or make compromises to meet short-term goals or deadlines. These shortcut solutions may work initially, but they often create more significant problems down the line, requiring refactoring, rewriting, or rearchitecting the codebase. Managing technology debt is crucial because if left unchecked, it can lead to a codebase that becomes increasingly difficult to maintain, extend, or enhance, ultimately slowing down development velocity and increasing the risk of bugs and system failures. #nocode #enterprisesoftware

Use comments to explain why, not what: In the realm of software development, comments play a crucial role in enhancing code readability and maintainability. However, it's essential to use comments judiciously and effectively. Rather than simply reiterating what the code does, focus on explaining why certain decisions were made or why specific approaches were chosen. Comments that elucidate the rationale behind the code provide valuable insights to fellow developers, enabling them to understand the context and intent behind the implementation. This not only facilitates collaboration but also makes it easier to maintain and modify the codebase in the future. When writing comments, strive to capture the high-level design considerations, algorithmic choices, or business requirements that influenced the code. Avoid stating the obvious or cluttering the code with redundant comments that merely echo what is already apparent from the code itself. By commenting wisely and using comments to elucidate the why rather than the what, developers can create more informative, insightful, and maintainable codebases that foster collaboration and facilitate long-term sustainability. Follow me: buymeacoffee.com/bmartrod

What are SOLID principles and why software developers should bother about it? When we are developing a new or exisitng a software project, we might have come across atleast one of the following issue. 📍 The use of duplicate code across the codebase. 📍 A class implementing a function which doesn't need to. 📍 Change in one class affecting other classes. 📍 One class is trying to take multiple responsibilities which could have been splitted across multiple classes. The SOLID principles helps us to solve the above mentioned problems by following five different design principles. So, let us go through the five principles that make up the SOLID principle. - S - Single Responsibility Principle - O - Open/Closed Principle - L - Liskov substitution Principle - I - Interface Segregation Principle - D - Dependency Inversion Principle In this post, I hope I gave you a clear explanation about what and why of the SOLID principles. I will explain each principle a day for the upcoming five days and complete the SOLID principles. Happy learning. 👨🎓 Feel free to post your suggestions. #software #softwaredeveloper #cleancode #backenddeveloper

We all hear the advice to "keep it simple," and code is no exception. It might seem like a no-brainer, but mastering this principle takes real dedication. Unlike building a bridge or a car, software has a nasty habit of morphing into a tangled mess. Just give a project a few years, and even the most seasoned developers will feel the struggle. This is why some engineers don't see software as “true” engineering. Traditional disciplines have clear plans and defined steps, resulting in a smooth-running machine. But software development is a chaotic beast with : A million ways to do one thing: Multiple solutions exist for most tasks, leading to confusion and potential inefficiency. Revolving doors: Teams constantly change, making past code a mystery to newcomers, adding complexity over time. Shifting targets: Business needs evolve, forcing software changes that can become a tangled web. Time pressure: Tight deadlines can lead to rushed solutions and messy code. Aging libraries: External tools used in the project (libraries) might become outdated, requiring updates and adaptations. The nature of software is dynamic, that's a fact. But to fight this ever-growing complexity, developers must seek for simplicity, regular refactoring code, questioning existing solutions and seeking more efficient approaches. #SoftwareEngineering

Quick understandability in existing software saves time, makes money. Software Engineers spend _a lot_ of time figuring out existing systems (https://lnkd.in/eBgqvz2E). If you can't or won't do what the feenk.com folks from the previous link do (which is a pity, for you), your engineers should opt for quick comprehension—even if it means eschewing nice-but-not-absolutely-necessary abstractions.

First, solve the problem. Then, write the code. - John Johnson In other words. Work the solution out on paper in steps, then start writing the code for it. Don't get tangled in the code and software design. https://buff.ly/3TT25yF #softwareEngineerng #solution #iteration