Becoming a Professional Programmer: Chapter 2

Your Team and Work Ethics

This series focuses on Continuous Personal Development and becoming a professional programmer. The first chapter covered mentorship, professionalism and continuous learning and gave many tips regarding changes to code, blind alleys and unit tests. 

The following chapter discusses the team, ethics and roles, and will touch on the topic of time management, meetings and how you can be responsible but still present.

Chapter 2: Your Team and Work Ethics

Your Team – Gelled Teams

Forming and disbanding a team is an expensive operation. Teams are harder to build than projects. 

Project owners who have a team dedicated to their project can count on the effort of that team. Therefore, it is better to form persistent teams that move together from one project to the next and can take on more than one project at a time. 

A gelled team will plan together, solve problems together, face issues together, and get things done. 

They can work miracles. They anticipate each other, cover for each other, support each other, and demand the best from each other. They make things happen.

Your Team – Being a Team Player

We hear that very often— do you consider yourself a good “team player?” What does that even mean?

  • It means playing your position as well as you possibly can
  • It means helping out your teammates when they get into a jam
  • A team player communicates frequently, keeps an eye out for his or her teammates, and executes his or her own responsibilities as well as possible.
Your Team – Quality Assurance (QA)

QA should find nothing! It’s unprofessional to purposely send code that you know to be faulty to QA.

  • Don’t use QA as the bug catchers!
  • Don’t send them code that they haven’t thoroughly checked!
  • Don’t depend on QA to find the bugs and report them back!

Will QA find bugs? Probably, so get ready to apologize and then figure out why those bugs managed to escape your notice and do something to prevent it from happening again.

QA and Development should be working together to ensure the quality of the system.

Work Ethics – Learning

Your career is your responsibility. 

  • Some employers are willing to buy you books and send you to training classes and conferences. Take advantage!
  • It is also not your employer’s responsibility to give you the time you need to learn.
  • Some employers may provide that time. Some employers may even demand that you take the time. They are doing you a favor.

Professionals spend time caring for their profession. That time is used to make yourself more valuable as a professional.

Work Ethics – Coding

First, your code must work

You must understand what problem you are solving and understand how to solve that problem. Often the customer’s requirements do not actually solve the customer’s problems. 

It is up to you to see this and negotiate with the customer to ensure that the customer’s true needs are met.

  • Your code must solve the problem set for you by the customer.
  • Your code must fit well into the existing system.
  • Your code must be readable by other programmers.
  • Don’t write code when you are tired! When you cannot concentrate and focus sufficiently, the code you write will be wrong.

Dedication and professionalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are balanced so that you can put in eight good hours per day.

Work Ethics – Arguments and disagreements

Force of will doesn’t settle disagreements for long. Data does.

Some folks will be passive-aggressive. They’ll agree just to end the argument and then sabotage the result by refusing to engage in the solution. This is probably the worst kind of unprofessional behavior there is. If you agree, then you must engage.

If an argument must truly be settled, then ask each of the arguers to present their case to the team in five minutes or less. Then have the team vote. The whole meeting will take less than fifteen minutes.

Work Ethics – Meetings

You do not have to attend every meeting you’re invited to. The person inviting you to a meeting is not responsible for managing your time.

Sometimes the meeting will be about something that you can contribute to but is not immediately significant to what you are currently doing. 

  • Your responsibility is to your projects first.
  • To use the participants’ time wisely, the meeting should have a clear agenda, with times for each topic and a stated goal.
  • Make sure you know what discussions are on the table, how much time is allotted for them, and what goal is to be achieved. If you can’t get a clear answer on these things, then politely decline to attend.

Meetings don’t always go as planned. Sometimes you find yourself sitting in a meeting that you would have declined had you known more. Sometimes new topics get added, or somebody’s pet dominates the discussion. 

You have an obligation to manage your time well. If you find yourself stuck in a meeting that is not a good use of your time, you need to find a way to politely exit that meeting. The important thing to realize is that remaining in a meeting that has become a waste of time for you, and to which you can no longer significantly contribute, is unprofessional.

Work Ethics – Agile Meetings
Stand-up meetings

These meetings are part of the Agile cannon. Their name comes from the fact that the participants are expected to stand while the meeting is in session. 

Each participant takes a turn to answer three questions:

  1. What did I do yesterday?
  2. What am I going to do today?
  3. What’s in my way?

That’s all. Each question should require no more than twenty seconds, so each participant should require no more than one minute. Even in a group of ten people this meeting should be over well before ten minutes has elapsed.

Sprint retrospective and demo

These meetings are conducted at the end of each iteration. Team members discuss what went right and what went wrong. Stakeholders see a demo of the newly working features.

  • These meetings can be badly abused and can soak up a lot of time, so schedule them 45 minutes before quitting time on the last day of the iteration. 
  • Allocate no more than 20 minutes for retrospective and 25 minutes for the demo. 
  • Remember, it’s only been a week or two so there shouldn’t be all that much to talk about.

Now that you’ve learned how meetings and teams can impact your professional development, in the next and final chapter of this series, we’ll cover estimates and how to ensure your team and management are on the same page with you.

Andrei Virabean

Andrei Virabean

Front-End Developer
Andrei is a Front-end developer, with 4+ years of experience in the IT industry. He’s always looking for new ways to improve his skills, learn and share his knowledge with his colleagues and the community.
Andrei Virabean

Latest posts by Andrei Virabean

Share This Article

Post A Comment