Forem: Hector Williams

960. Delete Columns to Make Sorted III

Hector Williams — Wed, 01 Apr 2026 15:31:29 +0000

In the last post, I discussed how recognizing patterns is important in solving coding challenges and discussed the Longest Increasing Subsequence. I shall talk about applying the basics in this problem to solve one variation of LIS. Follow me here, on Twitter, LinkedIn or Github for more.

Problem
You are given an array of n strings strs, all of the same length.

We may choose any deletion indices, and we delete all the characters in those indices for each string.

For example, if we have strs = ["abcdef","uvwxyz"] and deletion indices {0, 2, 3}, then the final array after deletions is ["bef", "vyz"].

Suppose we chose a set of deletion indices answer such that after deletions, the final array has every string (row) in lexicographic order. (i.e., (strs[0][0] <= strs[0][1] <= ... <= strs[0][strs[0].length - 1]), and (strs[1][0] <= strs[1][1] <= ... <= strs[1][strs[1].length - 1]), and so on). Return the minimum possible value of answer.length.

Example 1:

Input: strs = ["babca","bbazb"]
Output: 3
Explanation: After deleting columns 0, 1, and 4, the final array is strs = ["bc", "az"].
Both these rows are individually in lexicographic order (ie. strs[0][0] <= strs[0][1] and strs[1][0] <= strs[1][1]).
Note that strs[0] > strs[1] - the array strs is not necessarily in lexicographic order.
Example 2:

Input: strs = ["edcba"]
Output: 4
Explanation: If we delete less than 4 columns, the only row will not be lexicographically sorted.
Example 3:

Input: strs = ["ghi","def","abc"]
Output: 0
Explanation: All rows are already lexicographically sorted.

Constraints:

n == strs.length
1 <= n <= 100
1 <= strs[i].length <= 100
strs[i] consists of lowercase English letters.

Discussion

We apply the same principle in LIS with the double for loops.The only difference is we check all the characters in one column are less than or equal to all the characters in the other. We do this as we are trying to maximize the number of columns to be deleted.

Solution

Java

class Solution {
    public int minDeletionSize(String[] strs) {
     int length=strs[0].length();      
     int [] dp=new  int[length];          
     Arrays.fill(dp,1);
     for(int col=1;col<length;col++){       
      for(int j=0;j<col;j++){
        int numOfRows=0; 
        for(int i=0;i<strs.length;i++){
         char curr=strs[i].charAt(col);   
         char prev=strs[i].charAt(j);
         if(prev>curr) break;
         else numOfRows++;  
         }
         if(numOfRows==strs.length && dp[col]<=dp[j])dp[col]=dp[j]+1;          
        }
      }  
     Arrays.sort(dp);
     return length-dp[dp.length-1]; 
    }
}

public class Solution {
    public int MinDeletionSize(string[] strs) {
      int length=strs[0].Length;      
     int [] dp=new  int[length];          
     Array.Fill(dp,1);
     for(int col=1;col<length;col++){       
      for(int j=0;j<col;j++){
        int numOfRows=0; 
        for(int i=0;i<strs.Length;i++){
         char curr=strs[i][col];   
         char prev=strs[i][j];
         if(prev>curr) break;
         else numOfRows++;  
         }
         if(numOfRows==strs.Length && dp[col]<=dp[j])dp[col]=dp[j]+1;          
        }
      }  
     Array.Sort(dp);
     return length-dp[dp.Length-1];    
    }
}

C++

class Solution {
public:
    int minDeletionSize(vector<string>& strs) {
     string first=strs[0];
     int length=first.size();      
     vector<int> dp;          
     for(int i=0;i<length;i++)dp.push_back(1);
     for(int col=1;col<length;col++){       
      for(int j=0;j<col;j++){
        int numOfRows=0; 
        for(int i=0;i<strs.size();i++){
         string str= strs[i];  
         char curr=str[col];   
         char prev=str[j];
         if(prev>curr) break;
         else numOfRows++;  
         }
         if(numOfRows==strs.size() && dp[col]<=dp[j])dp[col]=dp[j]+1;          
        }
      }  
     std::sort(dp.begin(),dp.end());
     return length-dp[dp.size()-1];    
    }
};

300. Longest Increasing Subsequence

Hector Williams — Wed, 18 Mar 2026 18:02:33 +0000

A good way to master coding challenges is to recognize patterns. A good way to recognize patterns is to understand the basics. This may involve understanding one core problem and learning to apply it. Think of it as similar to learning to crawl before learning to walk and then learning to run. An example core problem is the Longest Increasing Subsequence. Variations of this problem are frequently asked. Follow me here, on Twitter, LinkedIn or Github for more.

Problem

Given an integer array nums, return the length of the longest strictly increasing subsequence.

Example 1:

Input: nums = [10,9,2,5,3,7,101,18]
Output: 4
Explanation: The longest increasing subsequence is [2,3,7,101], therefore the length is 4.
Example 2:

Input: nums = [0,1,0,3,2,3]
Output: 4
Example 3:

Input: nums = [7,7,7,7,7,7,7]
Output: 1

Constraints:

1 <= nums.length <= 2500
-104 <= nums[i] <= 104

Discussion

To solve, we use dynamic programming. We build a 1-dimensional array lengths to store the maximum length of the subsequences at each index and initialize it so that each value is 1.
Then we use two for loops. The first starts at the second index (index 1 in some programming languages) and iterates forward until the end of the array. We shall refer to it as i .
The second starts at the first index (index 0 in some languages) and iterates forward until it reaches i. We shall refer to it as j. If the number found at j is less than that found at i and lengths[i] is less than or equal to lengths[j], we recalculate the value at lengths[i] as lengths[i]=lengths[j]+1.
On finishing the double for loop,we sort lengths and return the last value which is the largest.

Solution

Java

class Solution {
    public int lengthOfLIS(int[] nums) {
     int [] lengths= new int[nums.length];
     for(int i=0;i<lengths.length;i++)lengths[i]=1;
     for(int i=1;i<nums.length;i++){
      for(int j=0;j<i;j++){
       if(nums[j]<nums[i] && lengths[i]<=lengths[j]) lengths[i]=lengths[j]+1;
      }
     }
     Arrays.sort(lengths);
     return lengths[lengths.length-1];
    }
}

public class Solution {
    public int LengthOfLIS(int[] nums) {
     int [] lengths= new int[nums.Length];
     int max=0;
     for(int i=0;i<lengths.Length;i++)lengths[i]=1;
     for(int i=1;i<nums.Length;i++){
      for(int j=0;j<i;j++){
       if(nums[j]<nums[i] && lengths[i]<=lengths[j]) lengths[i]=lengths[j]+1;
      }
     }
     for(int i=0;i<lengths.Length;i++)max=Math.Max(max,lengths[i]);
     return max;   
    }
}

C++

class Solution {
public:
    int lengthOfLIS(vector<int>& nums) {
     vector<int>lengths;
     int max=0;
     for(int i=0;i<nums.size();i++)lengths.push_back(1);
     for(int i=1;i<nums.size();i++){
      for(int j=0;j<i;j++){
       if(nums.at(j)<nums.at(i) && lengths.at(i)<=lengths.at(j)) lengths.at(i)=lengths.at(j)+1;
      }
     }
     for(int i=0;i<lengths.size();i++)max=std::max(max,lengths.at(i)); 
     return max;   
    }
};

Javascript

var lengthOfLIS = function(nums) {
 const lengths= [];
 let max=0;
 for(let i=0;i<nums.length;i++)lengths.push(1);
 for(let i=1;i<nums.length;i++){
  for(let j=0;j<i;j++){
   if(nums[j]<nums[i] && lengths[i]<=lengths[j]) lengths[i]=lengths[j]+1;
  }
 }
 for(let i=0;i<lengths.length;i++)max=Math.max(lengths[i],max);
 return max;
};

A practical guide to creating software applications regardless of programming language

Hector Williams — Wed, 04 Mar 2026 15:52:58 +0000

Introduction

Software engineering can be a lucrative, fulfilling career. The world runs on a variety of software applications, whether desktop, mobile or web. There are a lot of university degrees, courses and boot camps that teach the concepts of computer science, software engineering and different programming languages.
However, what is lacking and is needed is a guide to create software applications regardless of technology stacks and if the software is a mobile, desktop or web application. I attempt to provide such a guide below.

Basic Software Engineering Process

The process of building software can be divided into 6 steps: requirements gathering, designing the system, implementation of the system, testing, deployment and maintenance.

Requirements Gathering

The first step involves gathering the end-user requirements of the software to be designed. This step is necessary as without it, we can't design software that meets the end user's hopes and solves their problems.
This step involves communicating with the end user in an attempt to understand what problem they would like to solve. As end users may not be technical, steps should be taken to understand their points of view.
Once this is done, we can build a list of the end user requirements for the software to be designed. From this, we can get technical requirements.

Designing the system

The second step is designing the system so that it matches the user and technical requirements. This will involve making a tradeoff analysis of the benefits and drawbacks of various technologies and choosing the appropriate ones.
At the end of this step, we should know what programming languages, databases, operating systems and hardware we will be using and the architecture of the software. We should also have a list of modules that should comprimise the software.
We can then create a test environment to build the software and a production environment to deploy it once it is ready for the end users.

Implementation

Once the choice of technologies is made, the next step will involve the writing of the code in the programming languages and creation of the databases along with the creation of the user interface.

Testing

Once the code has been written it needs to be tested to ensure that it meets the technical and end user requirements. This can involve both user and integration testing. User testing ensures that all the modules work whilst integration testing is needed to ensure that the entire system works.
If all the necessary tests don't work, the programmer(s) will need to debug their code to ensure that it does. The testing can be done manually or using frameworks such as JUnit. It may also involve code reviews.

Deployment

After testing has been concluded, the software is deployed to the production environment. The end users are invited to use the system. If all goes well, the system is "live". If not, the programmers need to fix the system.

Maintenance

Over time, the user requirements may change, bugs may be discovered or new features may need to be added. The previous 5 steps will need to be done to make the changes. The changes need to be done in a manner so that the existing software's functionality isn't broken.

Additional Considerations

These are the considerations that need to be taken.

1) All steps should be documented for references in the future by different programmers.

2)The end users should be involved in all but the design and implementation stages.

3)User interfaces should be easy to use.

4) The code should be optimized for speed and space requirements and should be easy to change. They should also be written with scalability in mind.

5) Security should be a major consideration from start to finish.

Conclusion

I have given the list of steps to be taken to design a software application. These steps will work regardless of programming languages, databases, operating systems and whether the system is a mobile, desktop or web application. Please leave your opinions below.

LeetCode #1458.Max Dot Product of Two Subsequences

Hector Williams — Wed, 04 Feb 2026 17:31:45 +0000

Many engineers find leetcode problems hard and not a reflection of the actual work to do. I do have some sympathy for this view. Nonetheless, I do think that these questions can help practice and build programming skills. Due to this and the fact that these prop up in interviews, I will post discussions of these from time to time.Follow me on twitter,github or Linkedin for these and more.

Problem

Given two arrays nums1 and nums2.

Return the maximum dot product between non-empty subsequences of nums1 and nums2 with the same length.

A subsequence of an array is a new array which is formed from the original array by deleting some (can be none) of the characters without disturbing the relative positions of the remaining characters. (ie, [2,3,5] is a subsequence of [1,2,3,4,5] while [1,5,3] is not).

Example 1:

Input: nums1 = [2,1,-2,5], nums2 = [3,0,-6]
Output: 18
Explanation: Take subsequence [2,-2] from nums1 and subsequence [3,-6] from nums2.
Their dot product is (2*3 + (-2)*(-6)) = 18.
Example 2:

Input: nums1 = [3,-2], nums2 = [2,-6,7]
Output: 21
Explanation: Take subsequence [3] from nums1 and subsequence [7] from nums2.
Their dot product is (3*7) = 21.
Example 3:

Input: nums1 = [-1,-1], nums2 = [1,1]
Output: -1
Explanation: Take subsequence [-1] from nums1 and subsequence [1] from nums2.
Their dot product is -1.

Constraints:

1 <= nums1.length, nums2.length <= 500
-1000 <= nums1[i], nums2[i] <= 1000

Discussion

I was stumped by this question. I read the hints and somebody mentioned that it was similar to Longest Common Subsequence. That got me thinking. I had to use a 2-D dp array to get the result.

I also had to keep track of the multiplication of each number from each array along with the values from the previous row,current column and the previous column and current row.For edge cases I had to calculate the values for the first row and the first column.I came up with the solution below which passed all 70 cases.

Solution

class Solution {
    public int maxDotProduct(int[] nums1, int[] nums2) {
     int  [] [] dp=new int[nums1.length] [nums2.length];   
     int firstRowMax=nums1[0]*nums2[0];
     int answer=0;
     dp[0][0]=firstRowMax;
     for(int j=1;j<nums2.length;j++){
      int current=nums1[0]*nums2[j];
      firstRowMax=Math.max(firstRowMax,current);
      dp[0][j]=firstRowMax;
     }
     answer=firstRowMax;
     for(int i=1;i<nums1.length;i++){
      for(int j=0;j<nums2.length;j++){
        int current=nums1[i]*nums2[j];
        if(j==0) dp[i][j]=Math.max(dp[i-1][j],current);   
        else
         dp[i][j]=Math.max(dp[i-1][j-1]+current,Math.max(current,Math.max(dp[i-1][j],dp[i][j-1])));
        answer=Math.max(answer,dp[i][j]);
      }  
     }
     return answer;
    }
}

Why Programs Fail A Guide to Systematic Debugging by Andreas Zeller-A Book Review

Hector Williams — Wed, 21 Jan 2026 20:00:47 +0000

Introduction
A while back, I was given a list of books to read in order to become a world class software engineer. I have done previous reviews here. One of these books is Why Programs Fail A Guide to Systematic Debugging by Andreas Zeller.

As experienced engineers may know debugging is an important aspect of our jobs. In complex codebases, this may form the majority of our work. Unfortunately, it isn't something that is usually taught in degrees and bootcamps and we must learn it through practical experience whilst on the job.

This book helps to ease our task by introducing us to techniques used in debugging. The book is divided into 15 chapters. Each chapter is divided into 5 sections.

The first section discusses the title of the chapter in detail, the second the core concepts that software engineers should take, the third the tools to use, the fourth points to what we can also read and the final is a number of exercises to do.

How Do Bugs Arise?
In my experience, bugs are usually caused by incorrect assumptions about the code. Due to programmers being under tight deadlines, bugs are usually discovered by end users. They can usually be very costly. The author discusses this briefly at the end of chapter 1.

The first chapter discusses how failures in software arise. The author thinks it takes place in 3 stages:
i) The programmer creates a defect in the programming code.
ii) The defect causes an infection in the programming state
iii) The infection causes a failure-an externally observable failure.

The author lists a series of steps with the acronym TRAFFIC to debug a program.
i) Track: Create a problem in the programming database. In the second chapter, the author discusses how to keep track of the problems.
ii) Reproduce: Reproduce the failure.This is discussed in chapter 4.
iii) Automate: Automate and simplify the test case.
iv) Find Origins: Follow back the dependencies from the failure to possible infection origins.
v) Focus
vi) Isolate: Use the scientific method (see Chapter 6) to isolate the origin of the infection. Continue isolating origins transitively until you have an infection chain from defect to failure.
vii) Correct: Remove the defect and verify the success of your fix.

How to fix bugs?
As experienced developers know, there can be a number of issues that may arise when fixing a bug. First, we need to know whether the issue is truly fixed. To do this we may a correct understanding of the problem (the problem database mentioned above). Secondly, we need to also ensure that the fix doesn't cause any more problems.

My approach to debugging which has been gathered from working on different codebases over the years is to understand the problem, read the codebase, understand the workflow using logging statements, make the fix and adapt so that nothing else is broken, verify that the fix works using unit and integration testing and verify that nothing else has been broken running previous unit and integration tests.

Whilst this does work, it can be time consuming. The author makes a series of recommendations throughout the book that involves both tools and techniques to make the process more efficient.

The tools he suggests are debuggers and one of the techniques is an adaptation of the scientific method in a process known as scientific debugging.
The steps in this method are
i) Observe a failure.
ii) Invent a hypothesis as to the failure cause that is consistent with the observations.
iii)Use the hypothesis to make predictions.
iv)Test the hypothesis by experiments and further observations.
v) Repeat steps 3 and 4 until the hypothesis can no longer be refined.

Applying the scientific debugging should help the programmer to find the issue. The author spends a number of chapters discussing in detail how to do so. Once this is done, we must fix the problem. The author discusses in chapter 15.

As I mentioned above, we need to verify the fix resolves the problem and that it doesn't cause new problems. Other books discuss how to do this. Experienced engineers should recognize that testing will help with both.

Conclusion
This is a valuable, practical book. It is well organized and the summaries at the end of each chapter make it easy for programmers to refer to if they should forget or to get summaries of the main deductions. I recommend this book for all software engineers from novices to seniors.

A Book Review of Working Effectively With Legacy Code by Michael Feathers

Hector Williams — Wed, 07 Jan 2026 15:42:32 +0000

Introduction

A large part of software engineering involves not only designing and creating new programs, but also working with existing codebases. Due to a number of reasons, we may need to make changes to the codebase.
There are codebases where changes lead to an increasing number of problems. This is often referred to as legacy code, which the author defines as codebases without tests. The book Working Effectively With Legacy Code discusses how to work with such codebases.

The Problem

Changes in the system can lead to a disruption in the existing functionality of the system. Why then do we need to make changes to the existing system? The book gives 4 reasons.
1.Adding a feature
2.Fixing a bug
3.Improving the design
4.Optimizing resource usage

The challenge when making these changes is to preserve the existing functionality of the system. Preserving the behavior involves some risk. This is because the codebase may have a lot of entanglements and the code to be changed may have some dependencies. Thus changes may result in unwanted changes.

According to the book to mitigate risk, we have to ask 3 questions.

What changes do we have to make?
How will we know that we've done them correctly?
How will we know that we haven't broken anything?

Writing tests can help us with the process of mitigating risks as we know what works.

Solution
To solve the problem described above, the author suggests a legacy code change algorithm of 5 steps. These are:

1.Identify change points
2.Identify test points
3.Break dependencies
4.Write tests
5.Make changes and refactor

The rest of the book contains lots of details on how to execute the steps above.

Conclusion
In a nutshell, the way to deal with legacy codebases is to introduce tests that allow us to understand how the system works,to map out dependencies and where possible break them.The book has lots of details on doing this.
This is a useful and practical book that discusses how to deal with legacy codebases that are too often prevalent in the real world. I recommend this book for experienced and advanced engineers.
The advice given can be useful regardless of the programming languages used.

A Book Review of A Philosophy of Software Design-how to create software that is easy to maintain

Hector Williams — Wed, 19 Nov 2025 18:16:48 +0000

Introduction

A while back I was given a list of books to read in order to become a world class software engineer.One of these books was A Philosophy of Software Design by John Ousterhout. As the title implies, this book describes a way to design software. I would add how to design software that is easy to maintain.

As experienced engineers know, software engineering isn't just about creating software. User requirements may change in the future and new features may need to be added,bugs may be discovered in the existing functionality or changes in the existing codebase to make the code more efficient may be needed.

However, changing the existing codebase to incorporate these changes may interrupt existing functionality. This usually occurs because the code written was complex in the first place.

Complexity

The book describes two reasons for complexity:dependencies and obscurity. Dependency arises when one piece of code can't be changed without affecting others.Obscurity happens when important information isnt obvious.

The author also describes 3 symptoms of complexity.

1.Change Amplifications
A simple modification requires a lot of changes due to the fact that there are a lot of dependencies.

2.Cognitive Load
The developer needs to understand a lot of the codebase to make it easy to understand.

3.Unknown unknowns
It isn't obvious what pieces of code must be modified to complete a task or what information a developer must have to carry out the task successfully.In the author's opinion,this is the worst of the 3.

The author's proposed solution to eliminate or reduce code complexity is to make the code obvious. The book lists a number of ways that this can be done.

Programming Mindset

Software engineers are often in a rush to meet tight deadlines. As a result, they focus on writing code which works without thinking about the future. The author labels this as tactical programming and advises against it as due to its short sighted nature,it can lead to increases in the complexity of the code.

Instead the author recommends thinking with a strategic programming mindset. Here, developers must try not to introduce unnecessary complexity in the system. The focus must be on improving the design of the system where possible thus making it easier for other programmers to work in the future.

Modular Design

A technique the author recommends to reduce complexity is to use modules.This ensures that developers face a fraction of the system's overall completixy.The author advises to use deep modules-systems with a simple interface but a lot of complexity and advises against shallow modules-systems with a complex interface.

Information Hiding and Leakage

One way of creating deep modules is to use a technique known as information hiding. It involves providing other modules and users with a simple interface whilst hiding the implementation. People familiar with object oriented programming may know this as encapsulation.

In contrast, the author recommends against information leakage. This involves sharing of critical design information in multiple modules.This is a violation of the Dont Repeat Yourself principle of software engineering.

General purpose vs Special purpose Modules

Another approach the author proposes to reduce complexity is to use modules that are somewhat general purpose rather than special purpose. The former modules can cover a lot of use cases whilst the latter covers special cases. The difficulty is of course knowing what problems a module may solve today versus tomorrow.

Exception Handling

The author gives some advice that is controversial which is to define errors out of existence. This is because exceptions and errors may increase the code needed to deal with them and thus their complexity. However, this may not be always practical. I would say to minimize the errors you are dealing with where necessary.

Comments

The author makes another recommendation that is controversial. For those of us familiar with the book Clean Code by Uncle Bob, we were advised there to avoid comments where unnecessary. The author takes the opposite approach and recommends using comments as part of the system's design. We should start with comments.

He gives the reasons people give for not using comments and a reply as to why you should. He does raise some valid points. My recommendation having read both schools of thought is to use comments to explain design decisions and where the code may not be obvious. This should decrease the cognitive load.

Usage of Proper Names in Variables

The author recommends the use of variable names that are easy to understand, consistent and that create the right image in the minds of developers. This is one of the clean code guidelines recommended by Uncle Bob.

Consistency

The author recommends the use of consistency in naming, coding styles, interfaces, design patterns and invariants. This should reduce the cognitive load on developers. Those of us familiar with working on complex codebases will appreciate how much consistency helps.

Code Optimization

As experienced engineers know, the speed and memory usage of software is important when designing and implementing software. The author agrees but he does not think that this should come at the expense of increased code complexity.

Conclusion

The book argues that software design is an important part of the software engineering process. Designs where the code is obvious will make future work on that codebase easier. In contrast, code that is complex increases future work and makes bugs likelier.

This is something I agree with. Some of the recommendations are a bit controversial. You should look at the pros and cons of the error handling and comments advice before deciding.

The ideas put forward in this book are clear and practical. The book is short along with the chapters. In conclusion, I recommend this book for all software engineers.Which of Ousterhout’s design principles do you think is hardest to apply in your codebase, and why?

Designing Data-Intensive Applications [Book Review]-The Big Ideas Behind Reliable, Scalable and Maintainable Systems

Hector Williams — Wed, 05 Nov 2025 16:11:35 +0000

Introduction

Most backend developers eventually reach a point where they realize: learning another framework won’t meaningfully move them up to senior level. You can know Spring, Quarkus, Node, Nest, Django, whatever – and still not actually understand the deeper architectural forces that make large scale systems reliable.

That’s where “Designing Data-Intensive Applications” (DDIA) hits like a hammer.

This book doesn’t care about trends or hype. It forces you to understand the realities behind storage engines, distributed systems, data pipelines, fault tolerance, replication, consistency, and durability. And when you get this – you start thinking like a system designer, not just a code implementer.

This is a review, but also a recommendation: if you want to level up from mid-level to senior backend, this book should be on your “mandatory” list.

Why I read this Book

I follow many software engineers on LinkedIn and Twitter. One of them gave a list of books that I would need to become a world class engineer. This book was on that list. As the title suggests this book is about designing applications that process huge amounts of data-possibly limitless.

The single biggest value of the book

DDIA teaches you that modern backend engineering is less about functions and classes… and more about data flow and correctness across failure conditions. It is about building systems that can be reliable under any conditions, that are maintainable and easy to change and that can handle large amounts of data easily.
Most production systems are not CPU-bound.

They are data-bound.

Data movement.
Data reliability.
Data transformations.
Data structure evolution over time.

This book explains how real world systems survive reality: partial failures, retries, network partitions, schema drift, state synchronization, and replayability.

It gives you the mental model to see why large systems behave the way they do.

Topics Covered

The book is divided into 3 parts. Part I is titled Foundations of Data Systems. It is composed of 4 chapters. Chapter 1 introduces the concepts of reliability, scalability and maintainability. Chapter 2 discusses data models and compares relational and non relational databases. Chapter 3 discusses briefly the internals of databases. Chapter 4 discusses encoding data.
Part II is titled Distributed data and is divided into 5 chapters. Chapter 5 discusses Replication of databases across distributed systems and the issues involved. Chapter 6 discusses partitioning databases across distributed systems and the problems involved. Chapter 7 discusses the concept of transactions in databases. Chapter 8 discusses the problems encountered with distributed systems and chapter 9 discusses consistency and consensus.
Part III is titled Derived Data is divided into 3 chapters. Chapter 10 discusses batch processing, Chapter 11 discusses stream processing and Chapter 12 discusses the future of data systems.

5 concepts from DDIA that permanently improved how I think

1.Immutable logs create sanity and replayability.
Append-only logs aren’t just a Kafka pattern – they are a way to make systems auditable, recoverable, and debuggable.

2.Consistency is not binary.
There isn’t just “strong vs eventual”. There are reliability tradeoffs you choose. Most developers never consciously choose their consistency model. Seniors do.

3.Protocols matter more than frameworks.
When systems break across nodes or services, the protocol is what saves you. APIs are not just endpoints. They are agreements. Durable ones.

4.Batch vs stream is a philosophical divide.
Batch is a snapshot of the past. Streaming is the present unfolding in motion. Great systems often use both.

5.Schema evolution is a design problem, not an afterthought.
If you design your data structures to evolve safely… you avoid entire categories of distributed bugs.

You can take any one of these ideas and elevate your code review intuition immediately.

DDIA changes how you study and practice engineering

.This book indirectly forces a career mindset shift:

.Senior dev interviews? They’re testing these concepts.

.Architecture discussions at real companies? They’re anchored in these tradeoffs.

Debugging production outages? Almost always related to assumptions this book teaches you how to avoid.

It moves you away from “coding tasks” and into “system outcomes”.

That is literally the identity shift between mid-level and senior.

Who should read this book?

*mid-level backend devs who want to do proper system design

*people preparing for senior interviews or staff level interviews

*anyone going into infrastructure, distributed systems, or data engineering

future AppSec engineers (yes, security without understanding distributed systems is incomplete)

You don’t need to read it in one shot. This is a book you study over months and revisit repeatedly.

Final thoughts

“Designing Data-Intensive Applications” is not a coding book. It’s a “how the real world actually works” book.

If you want a single resource to help you break out of “framework-level thinking” and start thinking as a distributed systems engineer – this is it.

This book is where backend engineering grows up.

Review of the pragmatic programmer

Hector Williams — Wed, 01 Oct 2025 17:54:33 +0000

Review of The Pragmatic Programmer: Lessons for Every Developer

As a developer, I often look for books that go beyond syntax and frameworks—books that shape how I think about coding and problem-solving. While browsing my LinkedIn feed one day, I came across a list of recommended books to become a world-class software engineer by Neo Kim. Intrigued, I took notes and acquired most of the books on the list. I decided to start with The Pragmatic Programmer by Andrew Hunt and David Thomas, as its title suggested it would address the realities of being a programmer/software engineer.

Here’s what I learned from it and how it applies to my work in software development.

1. Think Critically, Not Just Code

The book emphasizes understanding the problem before writing code. Too often, developers jump straight into implementation. Hunt and Thomas remind us to:

Analyze requirements deeply

Question assumptions

Consider future maintainability

This mindset is invaluable in projects where complexity grows over time, like backend systems I've worked on in Java and Spring Boot. In the real world, the best software isn't the cleverest or the most efficient in terms of space and memory—but software that solves user problems. Designing such software involves understanding the problem through the eyes of the end user.

2. Write Flexible, Maintainable Code

Two principles stood out:

DRY (Don't Repeat Yourself): Avoid redundancy to make code easier to maintain.

Orthogonality: Keep modules independent to reduce unexpected side effects.

Following these principles has helped me refactor legacy code and improve code quality, even in nearshore development projects with tight deadlines. These ideas are similar to clean code practices but focus more on mindset and thinking like a pragmatic programmer, rather than just formatting or naming conventions.

3. Keep Learning

The authors stress that continuous learning is essential. Technology evolves fast, and the pragmatic programmer adapts, experiments, and improves constantly.

I’ve applied this by:

Exploring new frameworks like Spring Boot and Hibernate

Practicing coding challenges on LeetCode

Engaging in bug bounty hunting and security research

Hunt and Thomas reinforce the idea that you should invest in your knowledge portfolio—a collection of lessons, references, and tools that grow over time. This portfolio helps you think critically and tackle new problems effectively.

4. Practical, Everyday Advice

The book isn’t just theory; it includes actionable tips:

Using version control effectively

Writing clear, meaningful comments

Debugging strategies and problem-solving methods

Even small tips like these save hours of frustration in real-world development. Some ideas, like tracer bullets and rubber duck debugging, are small techniques that have an outsized impact on efficiency and clarity.

5. Boiling the Frog – Avoid Gradual Drift
One lesson that really stuck with me is the “boiling the frog” analogy. Hunt and Thomas explain that small, incremental compromises in code quality or practices—if ignored—can accumulate into big problems over time.

My take: “Just like a frog in gradually heated water won’t notice the danger until it’s too late, small shortcuts in code—quick fixes, skipping tests, ignoring refactoring—can silently create massive technical debt.”

Example: Adding quick fixes without refactoring might feel harmless at first, but over months it becomes much harder to maintain and debug.

Lesson: Address small issues immediately and consistently improve your codebase, even if it feels minor.

This analogy has changed how I approach long-term projects. It reinforces the importance of discipline, foresight, and small, steady improvements in coding practices.

6. Building a Knowledge Portfolio

Another principle I found extremely practical is the idea of a knowledge portfolio. It’s not just a concept—it’s about taking actionable steps to build and maintain it:

Collect lessons learned: Keep notes on challenges you’ve faced and how you solved them.

Save useful code snippets: Organize patterns, functions, or tricks you can reuse in future projects.

Maintain references and resources: Document books, articles, blog posts, or tutorials that helped you.

Review and update regularly: A portfolio is only valuable if you revisit it, prune outdated content, and add new insights.

Example: I maintain a folder of Java patterns, security tips, and LeetCode solutions that I can reference anytime—this saves hours and helps me think more like a “pragmatic programmer.”

💡 Application to SDLC: Maintaining a knowledge portfolio helps across the entire software development life cycle—from requirements gathering, design, and coding, to testing, deployment, and maintenance. Having organized lessons, snippets, and resources allows you to make informed decisions at every stage and avoid repeating mistakes.

This portfolio concept emphasizes continuous learning and documentation, making you more adaptable and effective as a developer.

Conclusion

The Pragmatic Programmer is more than a coding book—it’s a guide to thinking, designing, and working like a professional software developer. Whether you’re starting your career or are an experienced developer, the lessons in this book are timeless.

📚 Question for readers: Which book has influenced the way you code the most? I’d love to hear your recommendations!

Clean Coding Guidelines Every Developer Should Know

Hector Williams — Wed, 17 Sep 2025 15:35:11 +0000

Introduction
Software is a critical part of the modern world and it needs people to design, develop, test and maintain it. Due to the nature of life, there are often turnovers on a company's payroll. Employees retire, die or leave their role for other reasons. This presents the company with a challenge-how to create code that can be maintained and upgraded by other software engineers. Due to this, clean coding guidelines have been invented. The term was popularized by Robert C.Martin aka "Uncle Bob" and explained in his book. Clean Code These guidelines ensure that code is easy to read, easy to maintain and easy to change. They are as follows.

1.Meaningful Naming
Descriptive names should be used for variables, methods and classes that reflect their purpose and behavior. Single letter names should usually be avoided. This makes the code easier to read and understand and the logic easier to follow. It can also help in debugging the code.

Bad Example:

int d; // days since creation

Good Example:

int daysSinceCreation;

2. Small, Focused Functions

As an application of the Single Responsibility Principle, functions and methods should be designed so that they carry out one goal. They should also be small. This way functions will be easier to read ,reuse, test and maintain.

Bad Example:

void processOrder(Order order) {
   // validate order
   // calculate totals
   // apply discounts
   // update inventory
   // notify user
}

Good Example:

public class Example {
    public void doWork() {
        System.out.println("Working");
    }
}

3. Consistent Formatting
Formatting should be consistent. Spacing should be minimal in both the horizontal and vertical directions and the code should appear neat. Font sizes should be consistent. Following these rules should make the code easy to read.

Bad Example:

public class Example{
public void doWork( ){System.out.println("Working");}}

Good Example:

public class Example {
    public void doWork() {
        System.out.println("Working");
    }
}

4. Comment wisely
Comments are unnecessary if the code is well written. Good code will be self expressive. Don’t state the obvious. Use comments to explain “why” something is done, not “what.” If code is too confusing and you feel the need to over-comment, it’s usually a sign the code itself needs refactoring.

Bad Example:

i++; // increment i by 1

Good Example:

// Retry up to 3 times because the external API is unreliable
retryOperation();

5. Avoid Duplication
Duplicated code will lead to copies of the same code snippets all over the code base. Whenever a change needs to be made, the changes need to be made in a number of places. Otherwise, the code will break. Changes will also be time consuming. Hence, we need to centralize the code in order to make maintenance easier.

Bad Example:

if (userType.equals("Admin")) { /* logic */ }
if (userType.equals("Manager")) { /* same logic */ }

Good Example:

if (isPrivilegedUser(userType)) {
   // logic
}

6. Error Handling
As with life, the unexpected happens during software execution and we thus need to design and implement code in such a way to handle errors. Handling of the errors should also produce the correct error messages in order to debug the system. Proper error handling ensures failures are visible and recoverable, making systems more robust.

Bad Example:

try {
   doSomething();
} catch (Exception e) {
   // ignore
}

Good Example:

try {
   doSomething();
} catch (IOException e) {
   log.error("File operation failed", e);
   throw e; // or handle gracefully
}

7. KISS (Keep it Simple Stupid)
Write code that is code that’s easy to read, understand, and maintain. Avoid clever tricks or overly complex logic that only the original author can follow. Simpler code reduces bugs, makes future changes easier,helps onboards new members faster and encourages modularity.

Bad Example:

if ((user.isActive() && user.hasSubscription()) || 
    (user.isAdmin() && !user.hasSubscription() && config.isEnabled())) {
    allowAccess();
}//Hard to read,easy to make mistakes later.

Good Example:

if (canAccess(user)) {
    allowAccess();
}

private boolean canAccess(User user) {
    return (user.isActive() && user.hasSubscription()) || user.isAdmin();
}//The logic is isolated; The main flow is readable at a glance and easier to test and maintain.

8.Follow SOLID Principles

https://dev.to/hectorw_tt/the-solid-principles-of-object-oriented-programming-4bff

9.Write Tests
Tests are your safety net. Unit tests confirm small pieces work correctly, while integration tests check the bigger picture-how well multiple components work together. Writing tests ensures that your code does what it should do. Without tests, “clean” code can still hide regressions and future breakages. Clean code is testable code.

Example
Suppose you have a method that calculates the area of a rectangle:

public int area(int width, int height) {
    return width * height;
}

Unit Test


@Test
public void testArea() {
    Rectangle rect = new Rectangle();
    assertEquals(20, rect.area(4, 5));
    assertEquals(0, rect.area(0, 5));
}

10.Refactor Regularly
Refactoring means improving the structure of your code without changing its behavior. It’s like cleaning up a messy room: you don’t throw anything away, you just organize it so it’s easier to use.

Example:
Before refactoring:

void processOrders(List<Order> orders) {
    for (Order o : orders) {
        if (o.isValid() && !o.isShipped()) {
            double total = 0;
            for (Item i : o.getItems()) {
                total += i.getPrice() * i.getQuantity();
            }
            if (total > 1000) {
                // apply discount
            }
        }
    }
}

After refactoring:

void processOrders(List<Order> orders) {
    for (Order order : orders) {
        if (canProcess(order)) {
            applyDiscountIfNeeded(order);
        }
    }
}

private boolean canProcess(Order order) {
    return order.isValid() && !order.isShipped();
}

private void applyDiscountIfNeeded(Order order) {
    double total = calculateTotal(order);
    if (total > 1000) {
        applyDiscount(order);
    }
}

private double calculateTotal(Order order) {
    return order.getItems().stream()
                .mapToDouble(i -> i.getPrice() * i.getQuantity())
                .sum();
}

Conclusion
In the ever-evolving field of software development, writing clean code is paramount. It ensures that codebases are maintainable, scalable, and understandable, facilitating easier collaboration and long-term project success. In conclusion, following these habits will lead to code that is easy to read, maintain and update even when the team that is working with this codebase changes on a regular basis.What are your clean coding recommendations?

Additional Resources: Clean Code by Robert C.Martin

Secure Coding guidelines

Hector Williams — Wed, 03 Sep 2025 15:14:48 +0000

1.Introduction
Software now plays an important role in the modern world and is critical to aspects of life such as finance, health care, communication and even military. It is thus essential that we secure disruptions to this software from hackers and cyber criminals that affect its confidentiality, data integrity and availability. Currently, there are 2 ways to do this. One involves fixing code after the discovery of security bugs. This is risky because the damage may already be done. The other is to follow secure coding guidelines. This article discusses the principles involved.

2.Core Guidelines
Secure coding guidelines are the best practices, software engineers follow to prevent vulnerabilities and security flaws in software applications. The following is a list of such guidelines.

I.) Validate All Input.
Programs need input data but unfortunately they present an attack surface that can allow attackers to exploit the application and execute a potentially devastating attack. Examples include SQL injection and Cross Site Scripting (XSS) attacks. The software needs to be written so that the inputs match a whitelist of valid inputs or a blacklist of inputs that arent allowed.

II) Access Control
Software needs access control measures to ensure that users cant take actions that arent allowed to do.The access control measures take the form of authentication-ensuring that users are who they say are and authorization-ensuring that users are authorized to take whatever actions they desire to take.The principle of least privilege is followed where each user operates using the fewest number of privileges possible.

III) Data Protection & Cryptography
Data needs to be protected during communication from unauthorized eavesdropping. This can be done using cryptography which has been around for thousands of years and hashing which is used to ensure the integrity of data. That is data hasnt been tampered with.

IV) Error Handling & Logging
Error handling and logging are crucial parts of software applications. Unfortunately, they may produce information that will allow attackers to exploit. These are called information disclosure bugs. Care must be taken not to expose stack traces or sensitive information in error messages; to log messages but not sensitive information and to restrict the access to sensitive logs.

V)Session Management
Web applications often involve the use of sessions which allow users to login and have built in security mechanisms.These include the use of secure cookies; the invalidation of sessions after logging out and the regeneration of session ids after login.

3.The Defensive Programming Mindset

Defensive programming is about writing code with the assumption that things will go wrong. Instead of expecting the “happy path” to always succeed, you prepare for bad inputs, unexpected states, and failures. The goal is to make your code resilient, predictable, and secure—even when users (or attackers) try to break it.

Here are some key principles of the defensive mindset:

I)Assume inputs are malicious
Never trust data from users, APIs, or files. Validate and sanitize everything before using it. For example, if you expect an age field, don’t just check that it’s a number—also make sure it’s within a sensible range (e.g., 0–120).

II)Fail securely
When something goes wrong, default to the safest option. If a login check fails, deny access, even if you’re not sure why. Error handling should protect the system, not expose it.

III)Check for unexpected states
Defensive code doesn’t assume a function always returns valid data. Check for nulls, empty lists, or invalid responses. In Java, prefer Optional to handle absent values safely.

IV)Limit assumptions
Don’t assume a file exists, a network call will succeed, or a database query will always return results. Build in checks and fallback logic so the application remains stable.

V)Design with least privilege
Give code, services, and users only the access they truly need. If one part of the system is compromised, least privilege limits how far the damage can spread.

Adopting this mindset doesn’t just improve security—it makes your code more reliable and easier to maintain. When you think defensively, you’re not just coding for today’s happy path—you’re protecting against tomorrow’s worst-case scenarios.

4. Practical Tips

Writing secure code is easier when you adopt practical habits and tools. Here are some tips every developer should follow:

*I)Follow OWASP Secure Coding Practices *– Use the official OWASP guidelines as a baseline for secure development.

II)Use SAST/DAST tools – Static and dynamic analysis tools like SonarQube or OWASP Dependency Check help catch vulnerabilities early.

III)Keep dependencies updated – Outdated libraries are a common source of security flaws; regularly update and patch them.

IV)Perform code reviews with a security checklist – Incorporate security-focused questions during code reviews to catch risks before they reach production.

By integrating these practices into your workflow, you make secure coding a habit rather than an afterthought.

5.Conclusion

Secure coding isn’t just a checklist—it’s a mindset. By validating inputs, protecting data, handling errors carefully, and thinking defensively, developers can build software that is resilient, reliable, and resistant to attacks.

Adopting practical habits—like following OWASP guidelines, using analysis tools, keeping dependencies updated, and performing security-focused code reviews—turns secure coding from a one-time effort into a consistent practice.

Ultimately, writing secure code protects users, safeguards sensitive data, and saves organizations from costly breaches. The best time to start is today—every line of code you write with security in mind makes a difference. Like this article? Feel free to comment or share.

From Struggle to Solution-An Approach to Solving a programming problem using #650.Leetcode's 2 keys keyboard as an example

Hector Williams — Wed, 09 Jul 2025 18:15:06 +0000

1.Introduction
I regularly practice leetcode if not always on a daily basis. The reasons that I do this are: to keep my coding skills sharp, to deepen my understanding of algorithms and data structures and to prepare for coding challenges and technical interviews. Recently, I solved Leetcode's #650-the 2 keys keyboard using dynamic programming and I have decided to share my approach to solving this problem.Below is a description of the problem.

2 Keys Keyboard

There is only one character 'A' on the screen of a notepad. You can perform one of two operations on this notepad for each step:

Copy All: You can copy all the characters present on the screen (a partial copy is not allowed).
Paste: You can paste the characters which are copied last time.
Given an integer n, return the minimum number of operations to get the character 'A' exactly n times on the screen.

Example 1:

Input: n = 3
Output: 3
Explanation: Initially, we have one character 'A'.
In step 1, we use Copy All operation.
In step 2, we use Paste operation to get 'AA'.
In step 3, we use Paste operation to get 'AAA'.
Example 2:

Input: n = 1
Output: 0

Constraints:

1 <= n <= 1000

2.First Thoughts

I read the problem and the topics it was listed under. It was listed as Math and Dynamic Programming. My understanding was that there were 2 types of operations: a copy and paste and a paste. I was at first baffled and confused about where to start. I mean how could I minimize the number of operations to achieve this task? The fact that it was listed as dynamic programming gave me an idea-use a 1-d array to store the results of subproblems but I was still baffled.

3.Attempts & Failures
I read the hints. Only 1 was provided. It said "How many characters may be there in the clipboard at the last step if n = 3? n = 7? n = 10? n = 24?". This confused me more. I decided to try something. I could not come up with anything so I decided to reread the problem. On doing so, I realized my first error. 2 types of operations were allowed: a copy all and a paste.This helped. I did some thinking and realized that for a final string of 6,I could do a copy and paste of 3 characters and ditto for a string of 4 characters. It was progress but unfortunately not enough. I decided to read the discussion.

2 observations.
If n is a prime=> ans=n
If n=2^k=> ans=2*k
Something to do with prime factorization, maybe Sieve method can play again, not very necessary.
Have a nice day.

This was helpful but still I struggled.

4. The Breakthrough
I decided to give it a rest and to come back to it later. I was eating lunch and my mind thought about it. I had a realization!!! If the final string was 1000 characters, I could minimize by performing a copy and paste on a string of 500 problems. If it was prime, I could perform a copy and paste of 1 character n times. If it was a string of 27 characters, I could copy a string of 9 characters and paste it twice. So I found a solution. Create a 1-d array of length n+1.Iterate from the index 2 to the end of the array,if the current index is prime, record its number.Otherwise,get its greatest factor,go to that position in the array and calculate the current value by adding the dp value of the highest factor and the quotient of the current value/highest factor.

if(isPrime(i) dp[i]=i;
else dp[i]=dp[highestFactor(i)]+(i/highestFactor(i)).

With this in mind, I attempted a solution. I attempted to do this in Java. Here was my first solution.

class Solution {
    public int minSteps(int n) {
      int []dp= new int[n+1];
      for(int i=2;i<n+1;i++){
       if(isPrime(i))dp[i]=i;
       else {
        //System.out.println
        dp[i] =dp[highestDivisor(i)]+(i/highestDivisor(i));
       } 
      }  
      return dp[n];
    }

    public int highestDivisor(int n) {
        if (n <= 1) return -1; // No proper divisor exists for 0 or 1

        for (int i = n / 2; i >= 1; i--) {
            if (n % i == 0) {
                return i; // First divisor found from the top is the highest
            }
        }
        return -1; // Should never reach here for n > 1
    }

    public  boolean isPrime(int n) {
        if (n <= 1) return false; // 0 and 1 are not prime
        if (n <= 3) return true;  // 2 and 3 are prime
        if (n % 2 == 0 || n % 3 == 0) return false; // eliminate multiples of 2 and 3

        // Only check up to √n using 6k ± 1 optimization
        for (int i = 5; i * i <= n; i += 6) {
            if (n % i == 0 || n % (i + 2) == 0)
                return false;
        }
        return true;
    }
}

As part of my recent decision to try and get solutions in at least 4 languages (Java, c# ,c++ and javascript),I attempted to achieve solutions in c#,c++ and javascript. I first tried c# and the following solution was accepted.

public class Solution {
    public int MinSteps(int n) {
     int []dp= new int[n+1];
      for(int i=2;i<n+1;i++){
       if(IsPrime(i))dp[i]=i;
       else dp[i] =dp[HighestDivisor(i)]+(i/HighestDivisor(i));        
      }  
      return dp[n];
    }

    public int HighestDivisor(int n) {
        if (n <= 1) return -1; // No proper divisor exists for 0 or 1

        for (int i = n / 2; i >= 1; i--) {
            if (n % i == 0) {
                return i; // First divisor found from the top is the highest
            }
        }
        return -1; // Should never reach here for n > 1
    }

    public  bool IsPrime(int n) {
        if (n <= 1) return false; // 0 and 1 are not prime
        if (n <= 3) return true;  // 2 and 3 are prime
        if (n % 2 == 0 || n % 3 == 0) return false; // eliminate multiples of 2 and 3

        // Only check up to √n using 6k ± 1 optimization
        for (int i = 5; i * i <= n; i += 6) {
            if (n % i == 0 || n % (i + 2) == 0)
                return false;
        }
        return true;
    }
}

I then attempted c++ and my solution was again accepted.

class Solution {
public:
    int minSteps(int n) {
      vector<int>dp;
      for(int i=0;i<n+1;i++)dp.push_back(0);
      for(int i=2;i<n+1;i++){
       if(isPrime(i))dp[i]=i;
       else dp[i] =dp[highestDivisor(i)]+(i/highestDivisor(i));        
      }  
      return dp[n];
    }

    int highestDivisor(int n) {
        if (n <= 1) return -1; // No proper divisor exists for 0 or 1

        for (int i = n / 2; i >= 1; i--) {
            if (n % i == 0) {
                return i; // First divisor found from the top is the highest
            }
        }
        return -1; // Should never reach here for n > 1
    }

    bool isPrime(int n) {
        if (n <= 1) return false; // 0 and 1 are not prime
        if (n <= 3) return true;  // 2 and 3 are prime
        if (n % 2 == 0 || n % 3 == 0) return false; // eliminate multiples of 2 and 3

        // Only check up to √n using 6k ± 1 optimization
        for (int i = 5; i * i <= n; i += 6) {
            if (n % i == 0 || n % (i + 2) == 0)
                return false;
        }
        return true;
    }
};

Feeling very proud, I decided to try in javascript, I tried the following but saw that it was rejected.

var minSteps = function(n) {
      const []dp;
      for(let i=2;i<n+1;i++){
       let highestDivisor=i;
       for(let j=i/2;j>1;j--){
        if(i%j==0){
          highestDivisor=j;
          break;  
        }
       } 
       if(highestDivisor==i)dp[i]=i; 
       else dp[i] =dp[highestDivisor]+(i/highestDivisor);        
      }  
      return dp[n];  
};

I got a runtime error and was flabbergasted. I decided to come back later and to first attempt an optimized java solution. I decided to come up with the following approach. Instead of determining if a number is prime to find the highest divisor. I used the following which was accepted.

class Solution {
    public int minSteps(int n) {
      int []dp= new int[n+1];
      for(int i=2;i<n+1;i++){
       if(isPrime(i))dp[i]=i;
       else {
        //System.out.println
        dp[i] =dp[highestDivisor(i)]+(i/highestDivisor(i));
       } 
      }  
      return dp[n];
    }

    public int highestDivisor(int n) {
        if (n <= 1) return -1; // No proper divisor exists for 0 or 1

        for (int i = n / 2; i >= 1; i--) {
            if (n % i == 0) {
                return i; // First divisor found from the top is the highest
            }
        }
        return -1; // Should never reach here for n > 1
    }

    public  boolean isPrime(int n) {
        if (n <= 1) return false; // 0 and 1 are not prime
        if (n <= 3) return true;  // 2 and 3 are prime
        if (n % 2 == 0 || n % 3 == 0) return false; // eliminate multiples of 2 and 3

        // Only check up to √n using 6k ± 1 optimization
        for (int i = 5; i * i <= n; i += 6) {
            if (n % i == 0 || n % (i + 2) == 0)
                return false;
        }
        return true;
    }
}

It was accepted and was slightly better than the original. I felt happy. I decided to retry the javascript solution. I attempted to debug using print statements and realized that j was initialized as 1.5.So,I made some changes. I used j=i-1 and reran and came up with this solution which was accepted!!! I felt I was on a roll!!!

var minSteps = function(n) {
      const dp=[];
      for(let i=0;i<n+1;i++)dp.push(0);
      for(let i=2;i<n+1;i++){
       let highestDivisor=i;
       for(let j=i-1;j>1;j--){
        if(i%j==0){
          highestDivisor=j;
          break;  
        }
       } 
       if(highestDivisor==i)dp[i]=i; 
       else dp[i] =dp[highestDivisor]+(i/highestDivisor);        
      }
      return dp[n];  
};

5. Lessons Learned

This experience has taught me/helped reinforce a number of lessons.
1) Fully understand the problem a program/coding challenge is trying to solve by careful reading, asking the necessary questions. A problem cant be solved if you have misunderstood or dont understand it.

2) Research how previous or similar problems were solved by other programmers.

3) Develop a first draft solution to the problem.

4) If stuck, take a break. Solutions can come when your mind is at rest.

5) Optimize your solutions where possible. It can save time and memory. In production environments, this can make a noticeable difference.

6) Different programming languages handle variables differently. Understand how.

7) Debugging with print statements is an unsophisticated but simple way to troubleshoot.

6. Wrap-Up

I hope my post has been helpful, please feel free to like,comment and share. Please check out my github profile for this and more solutions.It is here : https://github.com/HectorwTT