DEV Community: Jean Roger Nigoumi Guiala

Change Management In Software Engineering

Jean Roger Nigoumi Guiala — Wed, 05 Jul 2023 19:04:00 +0000

Software engineering has an optimal goal : To solve problems, and that is usually done by providing a technical solution. But Software engineering is also about having the best process that can enable a team to find optimal solution to a problem.
When you grow in seniority, it becomes less about solving a specific task , but rather enabling the team and the system (process) so that the optimal solution can be found.
basically if we take the analogy of a factory, it's making sure that the production line keeps working efficiently.

To do that sometimes we need to change the way that we are doing things, the way we are coding , the technology we are using , our deployment process or even our whole architecture.
Being in charge of change as a subject expert sometimes means not only finding the right solution, but also support its adoption and implementation.
To be able to do that efficiently there are some stuff that needs to be done, some of them are :

Understanding the system and the tradeoff
Explaining the Why (the Vision)
Supporting the change.

Understanding the System.

This is one of the most important step. Usually as Senior or subject matter expert, we have our set of technologies or ways of doing things that we are used to and usually when tasking of finding new solution to a problem , we tend to go directly to the way we are used to doing things and that worked for us. It's not a bad thing as wisdom and knowledge are built through experience. But we need to be careful of the ecosystem we are in, the team , where the company is right now and other parameters.

So taking that into consideration, I think it's important to understand why this or that was done. why did they decide to use a VM and not containerized? (maybe time? maybe expertise ? or the infrastructure doesn't allow it ) . The most important thing here is not to come with some preconceived things in mind, but rather understand and ask questions because this will define how we implement things.
Understanding the system is not about knowing all the code or database , but rather finding the thought process behind the implementation: how things are tied together.

Explain the WHY? : Communication is key

The thing to understand here is : To be able to have a team rallied behind a vision, it's important for them to feel included and to know why the change is necessary.
Let's say you have a javascript codebase and because you have more and more people working on it , the need to have a certain structure becomes necessary thus you think about Typescript
If you just come to the team with "we are going to switch to typescript because it's better". You are going to create more confusion and also the team might be frustrated and feel like a change is imposed.

What needs to be done is understand the needs take time with the team to explain why the switch to typescript is important. Explain the Pro(s) , the con(s), the current process , how it will be with the implemented change , the goal behind that etc.
In my experience I have found this approach to rally the team. the team gets more excited if they subscribe to the vision and it makes the change smooth.
Ultimately this all comes down to : Communication and trust and these are the most important things.

Support the change

Last but not the least , and one of the most important step is to support the change and help the team.
This usually translate into :

Documenting what needs to be done and how ?
Implementing a template if needed on how to do it.
Follow up and make sure every question/concern finds an answer.

Basically this means : Lead the troop. As the domain expert it is your task to make sure they are equipped to do it and also to establish the guidelines.

If for example it is about moving the codebase to typescript, some of the tasks involve writing some Development principles that will define the way the code is written , tests are written, what to allow and not , best practices and design pattern.

Lastly one of the most important thing to note is that Change is done gradually. Do not try to change everything at first, start with the core or the smallest possible change that could lead the way.
This gives you time also to make sure that your system keeps working and also give time to the team to digest and understand what is being done gradually , rather than having one big change that will cause more confusion.

About me

I'm a Senior software Developer based in Canada, I love software architecture and building stuff.
Feel free to reach out to me on :
twitter : https://twitter.com/Guialajr
GitHub: https://github.com/jrking365
linkedIn: https://www.linkedin.com/in/jean-roger-nigoumi/

DRY: Don't Repeat Yourself

Jean Roger Nigoumi Guiala — Fri, 10 Mar 2023 18:02:50 +0000

A software engineering principle.

The problem

As a software developer , it's all about finding solutions to problems. Being able to build something that will solve a specific task.
When you are just starting your journey, it will often be around just finding a way to solve a problem, making something work by using a specific language/technology.

But at some point in your journey, it's not only about making it work , it's making sure you can be able to build on top of it; iterate and also allow people to contribute without impeding the work. There is that meme of coming back to the code you wrote a years ago and not understanding anything, I think it speaks to most of us in the software industry.

So it's not only about coding , but building something that can last using tools and principles; just like building a car , a house. And that is called Software engineering

On Wikipedia a software engineer is define as

a person who applies the principles of software engineering to design, develop, maintain, test, and evaluate computer software. The term programmer is sometimes used as a synonym, but may also lack connotations of engineering education or skills.

One of those principles is called DRY(Don't Repeat Yourself)

What is DRY ?

The Dry Principle that was popularized by the book The Pragmatic Programmer by Andy Hunt and Dave Thomas (That I encourage you to read of course), in that book they state that :

“every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

Basically , write only once. A rule of thumb is , if you find yourself writing something twice (a knowledge), it should be refactored(a single function, module, Abstract etc) and reused everywhere.

take a look at this example :

// not DRY

//file 1 
export function infoOfRectange(rectange) {
 const area = rectangle.length * rectangle.width; 

return {
 area, 
name: rectangle.name
}


//file 2 use the area to compare two rectangle
export function compare_area(rectangle1, rectangle2){
const area_rectangle1 = rectangle1.length * rectangle1.width;

const area_rectangle2 = rectangle2.length * rectangle2.width;

if(area_rectangle2 > area_rectangle2) return `${rectangle2.name} has a greater area than ${rectangle1.name}`

.....
}

Here we have two different function that uses the area of the rectangle, according to the definition, the area here is a knowledge so that knowledge needs to have a single representation.
So in our context , applying the DRY principle means having a single source of truth for that.

//dry
export function rectangle_area(length, width){
   return length * width;
}

//calling that function in `compare_area`

export function compare_area(rectangle1, rectangle2){
const area_rectangle1 = rectangle_area(rectangle1.length, rectangle1.width);

const area_rectangle2 = rectangle_area(rectangle2.length, rectangle2.width);
.....
}

Do not over engineer

Now that we have learned about Dry , One common mistake is over engineering , meaning refactoring when we don't need to. Because in software development every second cost something and also it's not necessary to bring complexity in our system when it's not needed meaning when we don't have duplicate, when a knowledge is only necessary in one place, it's already DRY and thus we don't need to separate everything.
I will refractor this because it could be useful later This statement should be a red flag and as we said above can cause many issue :

introducing more complexity
introducting more coupling between our features
Cost (is it necessary ?, can this time be spent on something else)

This introduce another principle known as KISS (Keep it Simple Stupid). it translates simply to Do not over engineer

If you have some other example or tips , feel free to share them in the comment section, as well as questions :).

You can follow me on twitter : @Guialajr

TIL: ruby factory bot and models association : `after(:build)`

Jean Roger Nigoumi Guiala — Wed, 25 Jan 2023 17:21:28 +0000

so I had an issue today , I have a model (we will call it StatusMain) that embeds another model(we will call it HistoricalStatus), an example below

# ruby '3'

class StatusMain
  include Mongoid::Document
  include Mongoid::Timestamps
  include AASM


  field :status, type: String, default: 'initiated'

  embeds_many :historical_statuses

  scope :initiated, -> { where(status: 'initiated') }
  scope :rejected, -> { where(status: 'rejected') }

  aasm column: :status do
    after_all_transitions :create_history

    state :initiated, initial: true
    state :rejected

    event :reject do
      transitions from: :initiated, to: :rejected
    end
  end

  def to_p
    Protos:: StatusInitial.new(
      id: id.as_json['$oid'],
      status: status,
      historical_statuses: historical_statuses.collect(&:to_p),
    )
  end

  private

  def create_history
    historical_statuses.create(
      status_main_id: id,
      status: aasm.to_state,
      created_at: Time.now,
      updated_at: Time.now,
    )
  end
end

and the historical_status model looks something like this

# ruby '3'

class HistoricalStatus
  include Mongoid::Document
  include Mongoid::Timestamps

  field :status_main_id, type: BSON::ObjectId
  field :status, type: String

  validates :status_main, presence: true
  validates :status, presence: true

  embedded_in :status_main

  def to_p
    Protos::HistoricalStatus.new(
      id: id.as_json['$oid'],
      status_main_id: status_main_id.as_json['$oid'],
      status: status,
      created_at: created_at.iso8601,
      updated_at: updated_at.iso8601,
    )
  end
end

so as you can see, the goal is to have the historical_status store every status transitions, and be embedded in my StatusMain

so as I was working on my spec , I designed my factories like this

status_main factory

# ruby '3'

FactoryBot.define do
  factory :status_main do
    status { 'initiated' }

    historical_statuses do
      [
        create(:historical_status, status_main: instance),
      ]
    end
  end
end

*historical_status factory

# ruby '3'

FactoryBot.define do
  factory :historical_status do
    status_main

    status_main_id { status_main.id }
    status { 'initiated' }

    trait :initiated do
      status { 'initiated' }
    end

    trait :rejected do
      status { 'rejected' }
    end
  end
end

So as you can see , in my factories, historical_status receives the status_main, that way , in status_main factory, I can create the historical_status with the correct status_main id.

The problem

so the issues I had is that , my status_main_id was always nil in my historical_status , that caused my test to fail because as you can guess .as_json['$oid'], does not exist on nil object.

Tried multiple things and I was surprised that my status_main_id is nil... How can it be nil when I'm passing it and doing it correctly.
Turns out my status_main object that I'm passing to historical_status was nil... now it's interesting, I continued investigating and found out , that my status_main object was set AFTER my historical_status was created, thus status_main_id was nil in historical_status.

The solution

let me first paste the updated factory and then I will explain.

# ruby '3'

FactoryBot.define do
  factory :historical_status do
    status_main

    status { 'initiated' }

    after(:build) do |historical_status, evaluator|
      historical_status.status_main_id = evaluator.status_main.id
    end

    trait :initiated do
      status { 'initiated' }
    end

    trait :rejected do
      status { 'rejected' }
    end
  end
end

so as you can notice , we now have an after(:build)
In the new factory, I'm using the after(:build) callback to set the status_main_id after the historical_status object has been built, and before it's saved, this way you can use the evaluator to get the id of the status_main and set it to the status_main_id field. This is important because the factory is trying to use the id of the status_main object that is associated with the historical_status and if the id is not set yet it will raise an error.

The evaluator is an instance of FactoryBot::Evaluator that is passed to the block, which is used to access the attributes of the factory and the objects that are being built/created by the factory.

By setting the status_main_id in the after(:build) callback, you ensure that the status_main_id field is set before the historical_status object is saved, and the id will be the same as the original status_main id field as wanted.

Conclusion

So here is what I learned today , feel free to comment a better way to achieve that if you have some, or if you can explain in a different way what is happening.

How do you discipline yourself? Idea and tools

Jean Roger Nigoumi Guiala — Mon, 19 Aug 2019 10:08:56 +0000

So lately I'm trying to be more organized and I'm trying to work more on personal projects (app, blogging, learning ...). But sometimes I just can't get my planning right And end up spending time doing the wrong stuff.
I will like to know how you keep motivated and focused on the right thing? what are the tools you use? What helped you in being more organized and focused.

Tips on improving Web accessibility

Jean Roger Nigoumi Guiala — Wed, 27 Feb 2019 12:49:28 +0000

When creating a website, what are your tips and tricks for managing accessibility?
For example, suppose you build a website, how do you imagine the whole process to make it as accessible as possible? what tools do you use to test? Also, how do you manage colors for color-blind readers?
I am really interested in knowing how you are doing to make the Web as accessible as possible.

How to keep calm while dealing with bugs?

Jean Roger Nigoumi Guiala — Mon, 13 Aug 2018 15:00:32 +0000

So i want us to discuss on a subject: How do you handle stress, how to keep cool while dealing with bugs? what is your tips, what do you do when you are coding and you spend hours on a bug and start getting angry or nervous?

Personally i just leave my computer for 15Min and try to do something else not computer related. What about you?

Imposter syndrome

Jean Roger Nigoumi Guiala — Sat, 11 Aug 2018 23:51:20 +0000

image source

So, i have been studying software engineering for almost 5 years, and i always had a problem, i always thought (and still now sometimes) that i don't know how to code, that I'm not even average, or that they are many genius programmers and I'm just one guy that struggle to write code.
But, two weeks ago, a friend of mine told me something that turned me upside down :

"you are a role model and i am working day and night to reach the coding skills that you have,i want to be just like you".

When she said that, i was shocked, so many things came to my mind :
how can she want to be just like me when i spend my time on stack-overflow, when i can't remember some basics CSS rules?
But i realized something, coding is a journey, you will never be the best but you always have to work to be the best.
Sometimes you may feel like you know nothing, but remember that those who answer your questions on Stack-overflow were one day just like you.
Remember that there is someone out there who is working and hoping someday to be like you, to reach the level where you are now.
So whenever the imposter syndrome hits you , just remember what you have already done and say to yourself that you are just starting your journey. Always say to yourself that you are the best, that you are going to be the best, self confidence is the key.

How to build a successful developer community

Jean Roger Nigoumi Guiala — Wed, 13 Dec 2017 13:47:58 +0000

So i'm planning to start a developer community here in cameroon (africa). It will be basically about sharing experience, learning and making some events... also i'm planning to create free hackathon, trainings.

I will like to have some of your tips on how to build a great dev community, what to do, how to organize etc. ;)

What are the Best Tips in implement TDD in a web application project

Jean Roger Nigoumi Guiala — Fri, 17 Nov 2017 14:41:28 +0000

I don't really understand the TDD (test Driven Development) i will like to have somme informations on the best way to implement it... some tools you use? how do you code?

What does it take to be a senior developer?

Jean Roger Nigoumi Guiala — Mon, 02 Oct 2017 03:20:41 +0000