Providing Value in the Programmer Role

When you have participated as a professional in the business community there are some things you can notice about the job and people that allow for tremendous growth. Some are more suited for programming than others to the shock of egalitarians. Regardless of innate abilities there are some things programmers can do to provide value over and above the average person just watching the clock for a paycheck.

Why bother going above and beyond? Because you’re not lazy or entitled, you want to excel, earn more, and provide the customer as much value as you can in the time you’re spending with them.

Curiosity is a boon in the discovery process(and empathy). To most accurately serve the customer we need to ask questions to find out what their vision is for the program. It might challenge the assumption someone knows all there is to know in human knowledge, and bruise egos, but that is really okay! If the programmer is not deeply curious about the needs of the customer how could they build the product suited to the need? They can’t. Many questions must be asked ahead of time unless the need is so routine and understood that few words convey to all what should be done.

Translating the business needs into technology choices and bringing those ideas into reality is the job in a nutshell.

When making technology decisions it can help to have that conversation with all the engineers involved. Usually the business owner will have heard some buzz words and ask if the programmers have experience with X, Y, and Z framework. That is interesting to know but less important than how well people understand the language fundamentals and how to build on those core concepts. If the team is weak in the languages being used no understanding of complicated frameworks will help them.

Before going into discuss technology choices with the team someone should have researched many of the available libraries, applications, services, and pricing. People are usually pretty good with identifying useful things to help out the project and knowing what is out there can help team members from the urge to reinvent the wheel. However, if a smart team member knows all the choices available and still recommends building from scratch it can be productive to listen to their reasoning.

Some helpful questions to ask during the technology selection process are:

  • What do you think of the analysis we have made of the technology choices?
  • Do you have familiarity with any?
  • Can you look through the documentation for each and see if it is high quality?
  • If we want to use X, will you do so happily, reluctantly, or oppose it?
  • Does our team have any objective ways of evaluating technology choice quality?
  • Does our team have the willingness or competence to do this project with these choices?
  • Do we need to make any prototypes in order to test the feasibility and performance of a technology or are we confident we can plan to go forward with a single choice?

Patience can also greatly help the process. Many times teams will assemble and look upon one another with confused looks on their faces and tentatively go along with a plan. Other times there will be active opposition to any plan, quality or not, and the process will be derailed for a time.

I’ve heard many programmers say “If we complete this too fast we’ll be out of a job.” The business owners say in frustration “If we could only finish this project I have a million ideas on what else we can do.” I’ll leave it to you to sort out who is telling the truth or what the motives there are.

The only way to counter the passive-aggression of co-workers is patience and persistence towards the business goals. I have yet to meet anyone in the business world who will acknowledge this fact that some people are much more suited to doing this work than others. There are really people that actively oppose progress in any way they can. Those who do not acknowledge reality and seek to understand the truth will continuously run projects into ruin.

Can people actually write logical expressions in code while being socially illogical? Yes, but it will be a total slog and all the joy will be sucked out of the room.

I dare you to consistently tell the truth around programmers who proclaim how logical they are. Take with you a haz-mat suit because it’s going to get exciting! You’ll witness the true horror of the false self, the logic-hating, and vomitous people-hating side that drives projects to ruin. That is how you identify the problem people but few have the guts to weed out those blood-suckers.

Psychological ego disturbances aside, projects can still be completed and adherence to principles is key. Deviation from the principles should be documented so ultimately the team can understand why something fails.

Don’t repeat yourself is a fine way to go. There are some systems where the code looks similar in a few places but slight differences cause confusion and bugs. If we find ourselves doing the same thing a lot we can move that code into a new module or library for reuse. Many will oppose having comments in the code but please consider documenting reusable method signatures at least.

Another good one is to stop and reach out for help if someone is stuck for a while especially for experienced programmers. Again, it challenges the ego to admit that they are not at the center of the universe and keeper of all knowledge. The less experienced programmers are valuable but the threshold of needing help should be extended to a higher time limit allowing for necessary problem solving skills to develop. Just don’t wait too long to go strike up conversations about ways to solve a difficult problem!

Validation is the hallmark of superior programmers. They will validate the input and give feedback so the data collected by users is of the highest quality. The experienced programmer knows that the business owner will always ask “What is all this shit data doing in the database?” if the programmer has not validated the inputs. In the worst cases the system can be vulnerable to attack if diligence is not placed on data validations.

In the end it’s up to each of us to drive quality and invite team members to do the right thing. By always telling the truth of our motivations we can inspire others to do the same. The quality of the project and performing to the satisfaction of people paying the bills is everything. It means having a spine. It means not giving into people’s feeble opposition to progress and pushing through it into success in the market.

I wish you the best of skill and success in your technology project!

Home Archive atom.xml Hexo⤴