Walking Through A Task

This article will take you from how to pick up a task to getting it through a 'Done State.'

You can choose a task, work on it, and throw it onto PR, and that's it, you're done with it. But the good among us supervise their tasks, ensuring they make it through a 'Done State.'

What's a done state?

At Writemedia, a done state is when a task has been tested by testers and it's ticked off from the task list.

What I'm about to say here is the true definition of a professional developer (Clean Coder). Knowing when to say no and striving to say yes; taking responsibility, becoming a team player, communicating, collaborating, working fast but without rushing, learning, practicing, studying, doing, teaching, and mentoring.

Responsibility -> Supervise your tasks throughout all their states and clean up your mess without leaving it in the hands of others, e.g., seniors.

Tips for taking Responsibility:

• Extend the existing codebase without adding any harm.
• Don't let your mistakes be found in the code review.
• Be certain it works before you push it. How? Test it, test it again, and test it even again.
• If there's an automated test in the system, ensure they all pass.
• Follow whatever structure or convention you find in the codebase.

It should be the goal that code reviewers or testers find nothing wrong. But when they do, act in horror and ask yourself how it happened, and take steps to prevent it in the future.

I remember some of my bugs they used to find are things that I assume they are working, thinking that my new changes have no effect on them. I know we're all striving to ensure our software is extendible without breaking, but until then, stop assuming and be sure. Test, test, and test again.

How to ensure that you're taking responsibility:

• Know your field -> Have good knowledge about the tools and technologies being used in your project.
• Know your domain -> Make it your responsibility to understand the domain of the solution you're working on. Working on Overtime management? Know about some Human Resources, accounting like payroll and incentives. Don't work on a spec without understanding why that spec makes sense to the business.
• Communicate -> Facing blockers? Let it out. Can't meet up with the target? Communicate it. As soon as you recognize abnormality, communicate it. Stop giving false delivery. Do not report undone tasks as done, almost, or already done when you're not done. Stop giving false promises and communicate the situation. I do not have to tell you how to communicate good news. I am very good at that, but waiting to communicate only good news is unprofessional. If you're a bad communicator like me, My employer gave me a tip which might work for you as well.

1. Stand up slack message -> Give a stand-up text on the slack channel every morning. Time is expensive, so keep it precise. Say what you did, what you're going to do, and what's on your way.
2. Eventual consistent update -> Give an update to a task's state when it changes. eg. Sent PR and Moving onto another task, the state of the two tasks have changed, update it.
3. Decision -> In a high-stakes/high-urgency situation where you have to decide whether to handle additional edge cases or rush your work, these are also the most important times to communicate/raise your challenges in Slack.

Task in progress:

• Preparation -> I know your task is hard regardless of the unit that was given it. Right now, you're set, and in your mind, there're a lot of competing factors juggling already at once.
• Dealing with background stress -> We all have stress, but it's best to calm your stress down than to let the noise bother you while you're coding.
• Coding -> Don't just write what works; write code that works well for everyone, including future employees. Don't just write rigid code that just works for the requirement without considering the edge cases.

I remember helping someone; after we've the working solution, I told them, let's consider this edge case and do so and so to prevent it in the near future. The one in question disagreed, insisting that this is what the requirement said for now, and that's how we'll leave it until when the requirement changes, then we can adjust. Hell no!!!! When will developers realize that requirements do not include edge cases?

• Debugging -> It's not a call to nature; it's part of the process. Know when to walk away and opt for collaboration.

Don't assign your task/bug to copilot or ChatGPT. These tools are great because they always give a result regardless of whether it's correct or wrong. Copilot is not good at doing the thinking for you; it's good at guessing what's on your mind. I think it's a bad idea to let it drive you to a solution instead of you driving it to the solution you desire.

Outstanding PR:

• Short -> Remove unnecessary spaces. If your formatting has an effect on the codebase, don't push it until you rinse the mess. Makes code review way easier.
• Simple ->Be pragmatic. Invest time in minimizing complexity. Send a PR that you yourself would be pleased to review. Review your PR first.
• Precise -> It's tempting to touch other parts of the code that solve certain issues but are not relevant to the current PR. Create separate tasks for it. Let the PR be specific to its purpose. Ensure it solves the task and solves it well.

Task To Do?

• When to say NO -> What cannot be done with your estimate cannot be done with any other adjustment to your estimate. Adjusting your estimates or tightening the schedules leads to pressure, and that's bug-prone.
• When to say YES -> Do not give vague responses or lack of commitment to your responsibility. Your task is not something you wish or hope to do; your task is not something you should get done; your task is not let's do it. When you say YES to a task, you'll do it, you mean to do it, and you actually do it.

Keep growing your career:

• Work ethic -> The earlier you realize that your career is your responsibility, the healthier your growth. I know we're given learning resources (books, courses) incentives. It's a good thing. We should capitalize on it, but it's worth noting that our career is our responsibility and not our employer's. How do I learn if I'm working the whole week? Here's the simple math: 168hrs in a week, 40hrs for your employer. You're left with 128hrs for sleep, duty, and learning. I don't care what you do when and in what quantity, but you've got to give yourself some reasonable amount of hours to invest in yourself. Ensure you maximize the amount of time you use for self improvement.
• Continuous learning -> Remember why you started programming before. If you're in this field just like me because of a hobby, and the only way to keep that hobby is most likely outside your working hours. Keep learning new things, new languages, concepts, design patterns, design principles, and architectures.

Here's the best way of learning:

• Practice -> Your daily job is not enough to be called practice; it's performance, and practice is what you apply outside your performance. The goal should be to become a rider of your software. Recall when you started off riding a bicycle; you could not even maintain your balance, you could not ride without full focus, without two hands gripping on the handles. But now you can ride while your mind is completely in a different place, you can ride with one or both hands off, and with these combined, you can find your way around in an emergency. You only achieve this because of practices; and it's not different when it comes to software development. You practice, practice, and practice until you become the rider of your career.
• Collaboration -> Many of us want to be left alone in our corners, actually thinking that it's helpful, but it's a disaster. The less collaboration a team has or an individual has is a higher hindrance to an overall success. Have you ever heard of this saying that, in order to go fast, you go alone, but in order to go far, you go with others? This quote doesn't apply in software development. In software development, in order to go both fast and far, you must collaborate.

The tasks that might take me days, I get them done in hours when I collaborate. I am a very poor collaborator, but I learn something new whenever I collaborate.

It's very common we have poor collaborators who don't take feedback, but it's worth noting that your partner or partners in collaboration might not see the direction you're heading in; it might take them time to figure out what you're trying to bring to the table. Be patient and communicate.

Below are a few types of pair programming I experienced:

Maintaining the thought process -> This is my favorite approach. When I'm asked for help, I just don't bring an alternative solution straight away. I follow the person's footsteps and provide guidance. While I watch them do it, whenever we stumble upon a bug, we fix it together. And even in situations where I could sense a bug in the near future, I communicate it and let us continue until we prove it before opting for an alternative solution. Many often, we do not need an alternative solution; we need the same solution but branched out when needed. And there are various situations when we will be faced with a few branches to choose from, and when necessary, we discuss the pros and cons of the option, and in the end, they decide, and I follow.

Going straight to an alternative solution -> I experience this way of collaboration often when I pair with my masters. Sometimes I couldn't figure out where they're heading to until we start implementing it. I hardly accept a solution until I understand the direction we're heading in, as opposed to simply accepting it because my masters suggest it. This ensures clarity and alignment before moving forward.

Assigning me your tasks -> In some pair programming, you see your pair relax and let you do all the thinking and coding. This is bad.

Assigning yourself my task -> Worse of all, when I call you for help and you wanted to do everything on your own. Seize my keyboard, seize my mouse, and seize my thought process; this is not just unprofessional, this is a disaster, I hate it.

During pairing, whoever amongst you speaks has a point, try to understand their point. Focus on their strength and not their weakness. Everyone should be open to interruption. One should be available to offering help whenever it's needed.

Professional Learn, practice, and collaborate. Encourage personal growth and development, Communication, and Collaboration in your work environment. Seating arrangement should encourage collaboration. I remember telling my coworkers about our isolated seating arrangement. The goal should be to arrange seats such that when one is crying inside, others can hear him crying and opt to help him even if he didn't ask for help. When someone offers you help, accept the help gratefully and offer yourself to that help. I am not saying to waste your time on pairing; if it's not working, kindly excuse yourself. Managing your time is your responsibility.

Self-improvement is a company's success.

Appendix:

• Be a team player -> Playing your role to the best of your ability and becoming a resource for the rest of the team members. Employer player cares about his performance and reputation; he delegates cost to future employees. Their codes are fluid, hard to change without breaking. Don't be an Employer player. Team player pays the cost now, writes clean code, tests their code. Do not rush no matter the stakes. Care about the team members, current or future employees. Know when to say no, especially in high stakes. Team players are professional.
• Be easy on yourself -> Go fast but do not rush. Do not over code days and nights because of high stakes. Take care of your energy and creativity. Sleep, Exercise, and play. Do not let situations or pressures rush you. If a situation changes how you behave, then you do not believe in your discipline. If you test in non-high stakes, then test even more in high stakes, whatever good practices or discipline you have in non-emergency, do more of that in an emergency. Do not boycott your discipline in an emergency.

Reference: Clean coder book and My employer, Ryan Dansie