DEV Community: Clement Samuel Goodness

Mistake 1: Skipping the Docs (Spoiler: They’re Goated)

Clement Samuel Goodness — Fri, 09 Oct 2026 04:38:05 +0000

As a rookie starting in software development, especially in the age of AI, I could easily skip the learning phase and jump straight into building.

But my experience during my undergraduate years taught me something: shaky foundations and an inadequate understanding of the tools you're working with will eventually come back to bite you — sometimes in ways you least expect.

After setting up my development environment and finalizing my database design, I initialized Prisma 8 in my DMS project.

Now, here's the thing about AI: if you don't provide enough context about what you're working on, its suggestions can be misleading or unsuitable for your setup.

ChatGPT and I brainstormed and came up with this folder structure for my project:

dms-v2/
├── src/
│   ├── auth/
│   ├── users/
│   ├── academic-session/
│   ├── documents/
│   ├── providers/
│   ├── common/
│   ├── app.module.ts
│   └── main.ts
│
├── logs/
├── test/
├── prisma/
├── package.json
└── ...

Notice that the prisma/ directory is outside src/? Good.

But Prisma 8 initially generated the directory inside src/. And you know what I did?

Yeah, you guessed right. I moved it to the project root. 😭

I thought everything was fine and continued writing my database models in contract.prisma.

I also set up a global Prisma module in another src/prisma/ directory so the generated Prisma client could be accessed through dependency injection across my NestJS modules.

At this point, I had two directories with different responsibilities: one at the project root for my Prisma schema and configuration, and another inside src/ for the generated client and Prisma service.

Then the problems started.

The first issue: NestJS compilation
I hit a compilation error when starting the NestJS application because a TypeScript file sat outside the directory covered by my TypeScript compilation configuration.

The second issue: Prisma couldn't find my schema
Prisma was also looking for the schema in its configured location, but I'd moved the relevant directory. As a result, subsequent Prisma commands couldn't find the schema where they expected it.

I had created these problems by changing the folder structure without fully understanding how Prisma's configuration and NestJS's compilation setup worked together.

The lesson
AI is a capable tool, but I believe it's only as good as the person using it. So, I try to understand the tools I'm working with and build a solid foundation in the field so I can evaluate the solutions AI suggests rather than accepting them blindly.

Reading through the Prisma 8 documentation helped me resolve these issues. It also helped me tackle subsequent problems, including cases where AI suggested Prisma ORM queries based on older versions.

Documentation might not always be the most exciting thing to read, but sometimes it's exactly what I need.

And that's one lesson I'm taking away from this experience.

DMS Database Design

Clement Samuel Goodness — Thu, 08 Oct 2026 02:36:30 +0000

After analyzing the paper-based system used to handle academic registration and gathering the necessary requirements, the next step in the implementation process was the architectural design.

I used standard software modelling techniques such as Data Flow Diagrams (DFDs), Class Diagrams, Sequence Diagrams, and Entity Relationship Diagrams (ERDs) to model the system.

The ERD was particularly important because it translated the conceptual data model of my DMS into a database schema. The entities in the ERD became tables, while their attributes became fields/columns in those tables.

The main entities in my design are:

User — Parent entity; also stores admin information.
Student — Child entity inheriting from User.
Staff — Child entity inheriting from User.
Department
Academic Session
Registration — Junction table created from the many-to-many relationship between Student and Academic Session.
Document — Stores records of documents uploaded by students.
Required Document — Stores the master list of documents required by the faculty.
Student Category — Categorizes students as fresher, sophomore, or finalist.
Required Document Map Student Category — Junction table created from the many-to-many relationship between Required Document and Student Category.
Notification

For the rebuild, I plan to use Prisma ORM in the application code to build and manage the database schema and handle communication between the application and the database.

Entity Relationships

The main relationships between my entities are:

Many Students belong to One Department (M:1)
Many Students register for Many Academic Sessions (M:N)
One Academic Session has Many Registrations (1:M)
One Student has Many Registrations (1:M)
One Student uploads Many Documents (1:M)
One Staff member reviews Many Documents (1:M)
Many Student Categories map to Many Required Documents (M:N)

The last relationship is particularly important to the DMS. Each student category requires a specific subset of the master document list, while an individual required document can apply to multiple student categories.

The junction table, Required Document Map Student Category, therefore connects the two entities:

One Student Category has Many mappings (1:M)
One Required Document has Many mappings (1:M)

Similarly, notifications can be associated with the users who receive them:

One Staff member receives Many Notifications (1:M)
One Student receives Many Notifications (1:M)

Highlights of the Design

Role-based extension:
Instead of putting every role-specific attribute directly into the User table, I separated role-specific data into related tables for Student and Staff, while keeping the common user information in the parent User entity.

Composite Key:
The Registration table uses a composite primary key consisting of matric_no and sessionId. This ensures that the same student cannot have multiple registration records for the same academic session.

Referential Integrity:
Foreign keys ensure that relationships between tables remain consistent by requiring referenced values to correspond to existing records.

I also use cascading deletes on appropriate relationships involving the User entity so that related records can be removed automatically when their parent record is deleted, helping prevent orphaned records.

This is the database structure I'm starting with for the rebuild. As I implement it with Prisma, I'll likely encounter decisions that require me to revisit parts of the design.

This was so insightful. Thank you, sire 🫡

Clement Samuel Goodness — Fri, 25 Sep 2026 12:32:31 +0000

Includes a helpful regex breakdown in the comments

Giorgi Kobaidze

Sep 21

Clean Code Is Not the Same as Clear Code: Comments Were Never the Problem

#discuss #programming #documentation #coding

143

125

9 min read

Setting up Development Environment

Clement Samuel Goodness — Thu, 24 Sep 2026 15:24:38 +0000

A little trip down memory lane 😅: while I was working on my final-year project (DMS) at university, I had to do a lot of research to make it a success.

My project falls under the software development domain, and I adopted Agile, a software development methodology. So, I already have the design and theoretical aspects — functional requirements, non-functional requirements, interface design, etc. — figured out.

Since this is a rebuild, I'll focus primarily on the actual implementation rather than going deep into the theoretical aspects. I'll still share some surface-level theoretical posts where necessary. Without further ado, let's get to the main thing:

I decided to use a monorepo for my rebuild this time. Instead of having separate repositories for my frontend app, backend app, and shared types, I can keep everything under one repository and manage it using npm workspaces, a feature of npm that allows multiple packages to be managed within a single repository.

My setup looks something like this 👇🏽

I also get to centralize my development tools. For example, I can use the same TypeScript version across the entire project by installing it in the root package.json. If other people want to contribute to the project in the future, they only have to clone one repository instead of cloning two or three repositories to work on a single application.

This is my first time using a monorepo in a project, so I went with npm workspaces to reduce configuration overhead and keep everything lightweight. From my research, other package managers also have workspace/monorepo capabilities, with differences in dependency management, commands, performance characteristics, and features.

I also came across tools like Nx and Turborepo. They offer more advanced capabilities, but they seem technically demanding for me at the moment. Hopefully, I'll get to explore them in the future.

AI gave me this diagram as a simple mental model:

                MONOREPO
                   │
         ┌─────────┴─────────┐
         │                   │
   Package manager      Build/task tools
         │                   │
   ┌─────┼─────┐         ┌───┴────┐
   │     │     │         │        │
  npm   pnpm  Yarn      Nx    Turborepo

I love this write-up mainly because of the practical steps included to stay sane and mentally healthy in this ever-evolving field. Thank you, sire 🫡

Clement Samuel Goodness — Fri, 18 Sep 2026 20:13:11 +0000

Resignations sparked by AI replacement fears

James Anderson

Sep 15

The Quiet Weight of Working in Tech in the AI Era

#discuss #mentalhealth #career #ai

151

110

7 min read

Start Here

Clement Samuel Goodness — Fri, 18 Sep 2026 12:22:29 +0000

Hi all 👋🏽, my name is Samuel, and I am a recent CS graduate. Over the past few years, I have had some exposure to the world of IT, and I have a few professional certifications in the field (Network+, Security+, etc.). However, during the final days of my undergraduate program at university, I decided to improve my programming skills, this time with a focus on backend development.

My final-year project was a web application: a Document Management System (DMS) designed to help college students, especially those at my institution, complete faculty-level academic registration digitally. The aim was to move the process from a paper-based system to a digital one.

Due to time constraints, I wasn't able to build the application to a satisfactory level (that didn't stop me from acing my final-year project though, lol 😂). But this time, I want to build it back up from scratch, with a minor tweak to the stack I used to develop the old system. I also want to use it as an avenue to dig deeper and sharpen my programming skills, including learning how to properly design and architect systems like an engineer.

I’ll be sharing my thought process, technical decisions, mistakes, and lessons as I work through this project. I’d also love to hear your perspectives, feedback, and constructive criticism along the way. If you have experience in backend development, system design, or anything related, your guidance is more than welcome. And hey, maybe I’ll make a few new friends along the way too. 🙂

Stay tuned.