Note: I’ve removed some old posts and so it may look like a big gap between now and my last post but I just decided to drop some things. I got a 3d printer and was going to write about it but I’ve decided I don’t want to write about that so I dropped the posts. Back to the intern.

Fly your own ship. There are a lot of ways this can be said but this is my favorite. As a developer you are responsible for providing the solution to a problem, therefore you should not let someone else solve the problem for you. It does not matter if you are a jr. developer, new to development or any other qualification, you must provide the solution.

This may sound a bit extreme and I’m sure the first though many people have is that often times the terms of a solution is dictated in the language of a contract, spec sheet or requirements list. All of these exist and absolutely have to be met. They are still just a set of problems to solve, and not a solution. Whatever is brought to you as part of the request for your work is part of the problem you are being asked to solve. Even if the language and coding style are dictated to you that just means that they are part of the problem. You must then find a solution that checks all or as many of the boxes as possible.

Why is this viewpoint important?

This viewpoint is important because as a developer you must take accountability for your work. The work you deliver is yours and whether or not it solves the problem will reflect on your work more than it will on anyone else. If someone starts micromanaging your work beyond assigning you the task that you need to do, then all kind of problems will present themselves. They may range from:

1. The actual goals of the project will be missed

2. The person trying to prescribe how to create your solution for you may not fully understand the underlying technologies

3. Compliance and or regulatory requirements might be missed

4. The solution may underperform

In most cases, you will be held accountable for the performance of the solution you deliver. It is not wise to let other people prescribe the parts of the solution for which your performance is being evaluated.

What does this look like in practice?

In any business environment, you must work with others. This is not optional. I am not advocating pushing others away or keeping them excluded, it is, in fact, the opposite. Let’s say you are working on a solution and a colleague has strong feelings about how the solution is going to be created but it is not their assignment. In this fake scenario, it is not practical to tell them to mind their own business. Perhaps the colleague has seniority or that you even know that they are probably right. This could be your boss trying to impoart a more specific vision that what was given to a customer. How do you prevent them from prescribing how to create your solution?

Define Scope, Capture Effort, Document results.

When someone comes to you during a development cycle these three things will not only let you maintain control of your solution but it will also make sure you are best able to serve your customer while taking additional input.

Define Scope:

Define what they want, their ideas etc and document this information in a simple format. Just a checklist is fine. If this changes what you have promised your customer you need to push back or go to your customer to see if the changes are acceptable. If it has no impact on the customer then ensure that the input meets all SOP criteria such as coding standards and any compliance concerns. The last thing to check is that this does not adversely impact your timeline. If it does then you need to go back to your customer to see if the advantages are worth the delay.

Capture Effort:

Every team or organization has a way for tracking effort. In Agile you use points and stories, in waterfall there might be some gannt chart with tasks assigned to it. Ensure that you capture the effort you spent working with this person if it was substantial. What substantial is totally depends on your organizational culture? If the other person does ANY work at all on your solution make sure that work is tracked and captured under their name and included for code reviews. If you are implementing their ideas then as long as any criteria that changed is updated that is really all there is to that. You just took someone’s advice.

Document Results:

Have some kind of retro with the person to decide if there was value in their input. If they made the project all the better then congratulate them and make sure they get credit for their good idea. If the idea didn’t work try to have a conversation about what came up and maybe some learnings you can both take away from the project. You may potentially need to schedule an additional round of work to fix any defects or adjust your work to make the changes effective.

This may seem like a lot but you need to apply scale to this type of behavior. If someone casually mentions a framework to accomplish your goal and doesn’t pursue it I do not recommend this process. This process is for when someone is trying to be highly involved in the specifics of how you accomplish your assigned work AFTER the requirements have been created. This could be after you wrote an Agile story with acceptance criteria or after a contract is signed. Simple advice, friendly help, or general brainstorming isn’t what I am addressing. It takes experience and practice to determine when a process like this is effective. My rule of them is if, after requirements/criteria have been created, someone comes to me and presents an idea or solution that is significantly different that what I had planned, significant being more than a 10-20% change depending on scope, and insist that this idea of theirs is important. This can include your customer. If your customer wants big changes you MUST document them. If they want to sit and tell you how to program each line and for some reason you don’t have the power to remove them(Overbearing Sr. Dev or your customer is your boss) then capture that extra time you spent. By creating visibility and transparency to your work in this way, it is easier to make sure external interrupts to your work are seen and are not misinterpreted as ineffective labor. My experience has been that this kind of visibility even helps the person coming to you see what kind of impact they are having, positive or negative.

A final note on this topic is that while it may sound as if this kind of input is bad it is not. You must learn to listen to the ideas of others, even people who know less about a topic than you. Good ideas come from everywhere. It also important to protect yourself and give credit to the source of great ideas. It makes your team better, which in turn, maybes everyone on the team better.