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:
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.
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.
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.
For agile teams, we don’t spend much time on documentation but documenting the following instead:
- Requirement definition (result from step 1.1 in“Software Engineering Effective Techniques - How to Analyze Software Requirements”);
- Requirement items & task items (result from step 3 in “Software Engineering Effective Techniques - How to Analyze Software Requirements”)
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:
(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 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.
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.
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!
