This article(originally published on medium) speaks about the fundamental ethics that every programmer/developer must follow, so, as to be one of the elites and the best in the evolving Software and Technology Industry.

Most developers fail to understand two things, firstly to understand

1. What do people mean when they say Pragmatic?

2. What does it take to become a programmer following Pragmatism?

In the simplest words that I can put up, being pragmatic can be interpreted as “Being Skilled in Craftsmanship”.

Pragmatic is all about practicality and being guided by “the priority of action over doctrine and of experience over fixed principles”.

“ I am this person who values craftsmanship, not because the end is a result of beauty, but an investment for my future. ”

Being pragmatic is about being a better developer. It is less about skills and more about experience and practice. It takes a lot of practice and experience to evolve as a pragmatic developer.

With every new experience, you take away something new that you learn, which definitely will connect to the dot as you move forward to face new challenges.

A developer must understand that every software that you develop is a craft. Each person who involves in building that craft is equally responsible. In such a scenario, how do you think you can pragmatism help?

For instance, consider a scenario of the construction of a house, in which various craftsmen have an important role to play. From Architect, Civil engineers to Painters, Laborers, all of them have their own skills that contribute to beautifying and completing the construction of the house.

In the same context, when you are a part of a team that is building a product, your individual contribution plays a very vital role. Irrespective of whether you are part of the backend/frontend/DevOps team, it doesn’t matter. Your contribution is important, as you, on the whole, will be representing the team building the product, not just as an individual.

As said, Pragmatism is more about how you can make a quality contribution to the team, not just as a developer but also as a team member.

Wondering, what does it take to follow pragmatism? Let us figure out what distinguishes Pragmatic Programmers from the crowd.

Being Responsible

In every project, there will definitely be problems. Problems are packed with every project you will be working on, despite taking every safety measure, i.e., cross verifying the Minutes of Meeting, documentation, testing, etc.

Despite taking all the measures, the possibilities of deliveries being delayed or unforeseen technical problems may come up, which is unavoidable at times.

Take responsibility and be accountable for your responsibility. Ensure you are communicating and keeping the team informed with all the updates.

The smallest mistakes during the presentation of your product to the client can lead to catastrophic damage to the reputation of the company or firm that you are representing.

Miscommunication or lack of communication can cause a lot of misleading in the team or within the project. When I was getting out of my Intern developer phase, we had to showcase our work to the client. The backend team had to make some changes on functionality at the last moment and had conveyed it to the mobile team but failed to inform it to the web team, expecting it would be conveyed. This ended up causing a lot of fuss.

Ensure that everything is conveyed to the team properly and avoid miscommunication. If you or the team feel the product is not in the best shape for the presentation, make sure you ask for an extension by taking responsibility for what has happened and ensuring not to repeat it.

If we can accept and be proud of our ability, we must accept and be honest about our shortcomings.

Assuming a situation where you are not able to solve a problem due to the shortcoming of resources or any other issue, avoid presenting the problem/shortcoming you are facing for the given problem statement. Rather present the reasons why you cannot solve them and provide them with alternative solutions.

Avoiding Tech Debts - Software Entropy

When you work in a team, you are a part of a group sailing in the same boat to build a product. A leak on a boat (similar to the wrong decision or code that you put in the codebase) can cause the boat to rot (technical debt) and sink, leading the boat to sink along with people in it.

It is our responsibility to fix those leaks in the first place when we figured it. Do not leave such loopholes open even if the deadline is near. If it is not a serious one, add ToDo and fix it later.

In one of the projects, I was working on, we initially did not structure the code when we had 2/3 services to deal with, due to time constraints. As we kept on building features on top of them, we ended up with 12 services and a whole codebase beyond repair and in the end, had to structure it in a single go which was such a pain.

Take the initiative, be the catalyst

Sometimes it so happens that we see some dirty code. When it does happen, try to convey that to your team. If time constraint does not allow the team to work on it and fix it, the best you can do is flag it.
In a situation when pieces of code are such that you have to fix it (severe bug), inform the team, take the initiative and responsibility of fixing the broken code and get it reviewed.

Gardening is the closest analogy to the development process. Just like how once you plant a sapling, and you need to take care of it every day, the same way as you build the code, ensure no part of the codebase is getting rotten. Once you develop the software, it is necessary to ensure and nourish it carefully.

Whenever new requirements pitch in, ensure that the development of the new feature doesn't affect or cause a lot of change in the existing functionality. Also, ensure that the addition of the new requirement is done in such a way that there is space for another set of new requirements.

Good enough isn’t good enough

How can we evaluate that the product/software we are building is good enough?

Good enough can have two meanings:

• Fully satisfactory: Requirements are met, expectations are satisfied, the underlying problem is solved.

• Barely adequate: Lowest level of performance that doesn't qualify as a failure

“Good Enough” isn’t “Good Enough”, in the sense that “Fully Satisfactory” is not the same as “Barely Adequate”.

“ How can we know if it’s good enough? ”

Perfect Software is a myth. Perhaps the key to the right balance is to understand the perceptions of the user and stakeholder.

The software/products you build are going to be used by a certain set of users or by general users. It is always best to get feedback from the end-users from their user experience. We can release a beta (release candidate) version, roll it out to your stakeholders, other team members, and possibly end-users for feedback.

As I said earlier, perfect software is a myth. Despite being a myth, there is something that we call a Minimum Viable Product ( MVP ). Every product that you are building, will have minimum viability to be accepted as a functional product.

MVP can be best described as a mid-point between the earlier stages of the development process and the final product, meeting all the fundamental requirements of the product.

Assume a mansion is under construction, initially when a mansion is under construction, it doesn't fit good for you to stay in it. But as the construction of the mansion is completed with required carpentry work, it becomes fit (viable) enough for you to stay.

Same way, when a product solves the fundamental needs of a given problem statement, it can be considered as a Minimum Viable Product.

“ Apple shipped the first version of Hypercard with about 500 known bugs in it, yet the product was a smashing success. The Hypercard QA team chose the right bugs to ship with. They also chose the right qualities… it isn’t the number of bugs that matters, it’s the effect of each bug. ”

- James Bach, person who coined the term Good Enough Software

As we move on, there definitely must have been a situation, where you might have added some functionality as an add-on even without being mentioned in requirements based on your astrological assumptions.

The add-on that you add to the project, might be the one thing that is not necessary and ruins the quality or standards of the project.

Identify the expectation based on the timeline and the resources given. Give the best for programmers, end-users, and future code maintainers. Nothing is always perfect. And most importantly, we need to know when to stop. Do not kill the good program with over-engineering.

Knowledge Portfolio, long-term investment

As you all know, Software and Technology Industry is an ever-changing landscape, where technology and the science behind the technology are evolving. With the pace of evolution, just as important as it is to be an expert in a field of certain technology, it is equally important to keep yourself updated with regard to that technology.

If you fail to keep yourself updated in regard to technology you are working on with the time you will be considered as an outdated resource.

Investing in Knowledge Portfolio is a type of investment that has an assured ROI.

“An investment in knowledge always pays the best interest.”

- Benjamin Franklin

Considering Knowledge Portfolio as an investment, you can classify the investments into two types:

• Low Risk, High Reward Investments

• High Risk, High Reward Investments

Low Risk, High Reward Investments are the types of investment where you are investing your time in learning and sharpening your skills in the technology that you are proficient in.

On the other hand, High Risk, High Reward Investments are those investments in the knowledge portfolio, where you are not sure about the future of that technology but currently is in the trends.

You should aim to find emerging technologies and learn them before they become popular.

“ Learning Java when it first came out may have been risky, but it paid off handsomely for the early adopters who are now at the top of that field. ”

— The Pragmatic Programmer

Keep investing regularly with diverse technologies. Always stay contained with the spirit of learning new things that may enlighten you to think out of the box.

Always be skeptical and analyze what you have heard or read about.

Communication, a lethal weapon

Communication is an important factor that as a developer we fail to fulfill sometimes. Communication is an art of transmitting information, ideas, and attitude from one person to another. Communication is a process of meaningful interaction among humans.

As a developer, we have to communicate at various levels, starting from communication within the team up to communication with the client.

Most of the time we fail to identify and understand the WISDOM principle behind communication.

One of the most important factors that play a vital role in realizing who you are conveying your idea.

As a product owner, I would want to know about the product based on it’s viability and the problem that it solves.
As a developer, I would want to know how we can solve the problem statement or deal with it, technically.
As an end-user or client, I would want to know more about how does the product works and how does that fulfil all my requirements.

This is certainly something that we always miss out on. Despite being the best communicator in the team, if you explain the aspects and flaws of the products technically to the client, it is less likely expected for them to understand it unless they belong to an IT background or have some prior knowledge.

As far as effective communication is considered, listening is also as important as conveying your idea. Always be an attentive listener.

Finally, how you communicate your idea to the other person contributes to building an effective exchange of ideas. Every meeting not necessarily has to be some sort of presentation of your idea. Some might just be about mailing minutes of the meeting and cross verifying it.

And however you are doing it, make sure you are doing it right. Even when you write emails or minutes of the meeting, ensure there are no grammatical errors or spelling mistakes.

This is vital because, when these mistakes happen with the client we are working with, it speaks more about the firm you are representing and not just yourself. That is why it is necessary to be careful regarding these minute knots.

Note: Communication is not just about what you say. It is about what you say and the way you

Always respond to emails, missed calls, Slack messages, whatever.

Note: You don’t have to immediately respond to everything!

Documentation is another means of communication, basically a written proof of the process flow of functionality. In the software and technology industry, documentation plays an important role in keeping requirements intact to the final functionality.

Always ensure that you document the minutes of every meeting with the client and within the team.

I know this has been a bit longer post than expected. If you got this far, I appreciate your patience and thank you for your time. I had too many thoughts to put up, but adding them all onto a single post may not have been the right idea. Anyhow, wrapping up the post, these simple baby steps are the fundamental ethics that will make you stand out from the rest of the developers out there. As a developer, we should and must strive to be better than we were yesterday. That was my first step towards being pragmatic, and probably, I believe it could be yours as well.

I hope this article has helped to figure those minute things that you missed out on. Stay tuned for more.

Happy Learning! :)