Think with Enlab

Diving deep into the ocean of technology

Stay Connected. No spam!

Software Engineering Effective Techniques - The Right Mindset of a Professional

 

In software engineering, besides skills, mindset plays an important role in developing your professionalism. In this article, I’d like to share some aspects that we should understand right and act accordingly.

 

What Is The Purpose of Software

As a developer, your purpose is not to write complex lines of code but to deliver simple to use yet easy to develop and maintain software. Bad software is one that doesn’t help users much but is complex to develop and maintain.

 

Simplicity

“Simplicity is the ultimate sophistication” -  Leonardo da Vinci

Programming should be the act of solving complex problems with simple solutions. A good developer writes codes that are easy to understand, enhance, and maintain. A trap that many developers often fall into is to create clever yet complicated algorithms. This is because they love to do clever things but forget the purpose of the software.

 

Making a Decision in Software Engineering

“The desirability of any change is directly proportional to the change’s value and inversely proportional to the effort involved in making the change.” - Code Simplicity

In another format of the formula: D = V/E where D is desirability, V is the value, and E is the effort.

When it comes to decision-making for any changes in your software development, applying the above formula will benefit you a lot.

 

The Definition of Done

Working with others becomes easier if you gain their trust. In a professional environment, your quality of work and attitude allow others to trust you. Therefore, you should always double-check your work before marking it as DONE. And be always open to receive feedback from your colleagues to improve yourself.

 

Collective Ownership

It’s important to know that all artifacts you produce while working in a team are owned by the team, not by any particular member. That also means you take responsibility to deliver the best result, but you don’t necessarily own it. Certainly, you get credit for it. Once you understand this, you will be very open to receiving any feedback or comments about your artifacts.

 

Issue Escalation

Once facing an issue that you can’t resolve, escalate it to your team lead. Key things to remember when escalating an issue:
Know your issue well and explain it to your team leader simply and concisely. Otherwise, it will steal your team leader’s time and discourage him/her from helping you. Once escalated, you need to follow up with your team leader to resolving it actively. That means you own your issue, not your leader.

 

Just-In-Time (In Opposite to Just-In-Case)

Especially when working in an agile team, you should create things to use for now, not for the future as they are likely to become unnecessary. This idea can be applied in many aspects of your work, including:

Planning

In software engineering, you need to think big but start small. Yes, you need to have a master plan (what to deliver by when - the release roadmap), but you should follow a detailed plan (daily/weekly/sprint objectives). Therefore, you should not create detailed plans for more than a sprint (2 weeks) following a release roadmap.

 

Requirement Analysis

To be just-in-time when analyzing requirements, you need to divide them into phases:

  • Initial Analysis: At this stage, you need to collect, understand, and define the requirements (learn more from step 1 in “Software Engineering Effective Techniques - How to Analyze Software Requirements”).
  • Feature Set Analysis: At this stage, you need to break down the requirements (features) defined in the Initial Analysis stage into requirement items or sub-requirements (learn more from step 2 in “Software Engineering Effective Techniques - How to Analyze Software Requirements”). To do this, you might need to discuss the details with clients or domain experts to remove uncertainties.
  • Story/Requirement Analysis: At this stage, you need to break down requirement items into tasks (learn more from step 3 in “Software Engineering Effective Techniques - How to Analyze Software Requirements”).
  • After-Action Analysis: This stage happens when you have finished a sprint or delivered some set of features. You then should collect feedback/comments from end-users to refine requirements.

 

Architecture/Design

Simplicity is key. At the start of the project, it doesn’t make sense to build a fancy architecture that is going to change anyway. You should build just enough architecture that supports the current user stories. The architecture/design will emerge when you complete more user stories, which will show via frequent code refactoring.

 

Documentation

For agile teams, we don’t spend much time on documentation but documenting the following instead:

 

Collaboration

Only focus on daily/weekly/sprint objectives. A virtual Kanban board is where to organize all the work items and team members collaborate using this single board.

 

Accomplishments vs. Tasks

Every day you might work on many tasks and many times concurrently (multitasking) but at the end of the day, your accomplishments matter. Tasks are like artifacts and accomplishments are like products. Customers need your products, not artifacts.

 

Customer-Oriented Service Attitude

Your highest priority is to satisfy the customer through the early and continuous delivery of valuable products.

 

Effective Communication

There are tons of methods, tools, and tips to communicate effectively, so you need to learn to use them. However, the key to effective communication is to understand that communication takes time. And so, do whatever you need to do to communicate well but remember to save your time and others involved in your communication). Here are several important notes:

Using Instant Messaging (IM)

(Skype, Slack, etc.)
Only use IM for urgent matters to not disturb recipients. Depending on the situation, you need to decide if it’s urgent or not. Consider the following situations:

  • You found an issue checking in your source code due to conflict, and you don’t know how to merge correctly: Should use Skype to raise this issue but remember to provide enough detail for others to help you. A screenshot showing what lines of code conflicts will help in this case.
  • You wrote a shared method/function, and you think it’s very helpful and can be reused by others in the team: Should inform all members via Skype about where to get the method and how to use it if necessary. Afterward, it is even better that you document it on some kind of wiki page for everyone to read when in need.
  • You saw an issue/error to which you already found the solution, and you think many will likely make this mistake: Should inform the team over Skype letting them know how to avoid it.
  • When you’re a team leader during code or progress review, and you notice issues or quality problems. Some of them are critical and urgent, some are not: In this case, if the critical and urgent issues are not addressed immediately, and team members might introduce more problems, you should call for a short meeting to address them. When addressing issues/problems, always provide solutions and ensure the whole team gets the point and knows how to avoid it. For non-urgent issues, you should document on a wiki page then inform the team.

Besides, when using instant messaging, try to convey the whole point in a single message rather than splitting it into multiple messages.

 

In-person discussion

In an agile team, face-to-face conversation is the most effective way to communicate if you apply the following:

  • Do your homework: prepare your points before facing others.
  • When in the discussion, try to address point by point. You might start the conversation like this “Hey, I have a few points to clarify with you. First, …; second, …”.
  • Do not jump into the discussion without setting up an appointment, unless you have urgent matters to discuss.

 

Using email

Emailing is for asynchronous communication so make sure you use it for non-urgent matters.

 

Failing to Plan Is Planning to Fail

Lastly, remember that if you fail to plan then you’re planning to fail. Therefore, build yourself a habit of never working without a plan. Planning is simply to list out what (tasks) you need to do, their priorities, and when to deliver the results. To acquire good planning skills, you have to practice daily, weekly, and monthly. Once you can do a personal monthly plan effectively, it’s time to move on to planning for projects, teams, or company-wide levels.

 

Final Thoughts

I can’t stress enough how important the right mindset contributes to your success, not just in software development but in all aspects of your life. Learn and apply them, and always reflect them in your daily life to build your formula for success.

Thanks for reading. I hope this guide can help you out!

 

CTA Enlab Software

About the author

Vinh Tran

Hi, my name's Vinh and I'm the CEO of Enlab Software. I'm passionate about building world-class digital products, helping my team become mature in their careers, and creating an environment where people find purpose and meaning in life.

Up Next

Big Data Technologies Transforming Software Development
July 05, 2024 by Dat Le
In the rapidly evolving world of software development, Big Data stands out as a transformative force....
June 27, 2024 by Dat Le
In today's rapidly evolving digital landscape, secure coding practices are paramount to safeguarding applications from a...
June 20, 2024 by Dat Le
In the rapidly evolving digital landscape, the role of User Interface (UI) and User Experience (UX)...
Leveraging UX Design Principles in Software Development
June 17, 2024 by Dat Le
In the dynamic world of software development, one element has emerged as crucial to success: User...
Roll to Top

Can we send you our next blog posts? Only the best stuffs.

Subscribe