Why Company Culture is Important to Your Career as a Software Engineer
freeCodeCamp
By Jennifer Bland
The impact of a company’s culture is reflected in a company’s ability to achieve their goals and productivity levels, and in their employees’ satisfaction. The company culture can make or break a business.
Yet, company culture is the one thing that many aspiring programmers overlook in their job search. Unfortunately, they usually find out after accepting a job offer that they are working for a company with a very poor culture. That oversight can have a negative impact on their career.
To better explain the impact of company culture, I am going to use experiences from my career to illustrate.
Working hours
The 9 a.m. to 5 p.m., 40-hour work week is a reflection of how work was performed in the Industrial Revolution. During this time, workers punched a clock which measured the amount of time worked. Management used the punch clock to gauge employee productivity.
Today’s software engineers are smart, creative people who prefer to work in an autonomous environment to create their best work. Unfortunately, at some companies, management still clings to hours worked as a barometer of productivity.
The following examples are how two management teams from two different companies that I worked for view work hours.
First company
This company provided flexibility to employees in terms of when they started and ended their work day. The only requirement was that every member of the team had to be available during the same six-hour window during the day.
This provided flexibility to employees so that they could schedule doctor visits, receive home deliveries, tend to their homes and car repairs, and so on.
Second company
Management sent an email to every programmer, asking them to declare their time of arrival at and their time of departure from work every day. Later, we received another email explaining that people were not adhering to when they said they were arriving at and leaving from work. Shortly thereafter, upper management was sitting at the front of the office when people arrived at work. They were probably noting when their employees were arriving at work.
Normally I arrived at work around 8:00 a.m. One morning I arrived at work at 8:30 a.m. Upper management commented that I was late for work. There were about 20 people that worked in the same office, and I was the second programmer to arrive at work that day.
How to avoid it
Avoid companies that measure your success by when you arrive at and leave from the office. Instead, work for companies that measure your success by the goals you meet. When interviewing with companies, ask if they have core work hours or standardized hours.
Companies with core work hours require that every member of their team be available during those hours. Employees can set their start and departure time based on these core hours. For example, if core work hours are 10 a.m. — 4 p.m., employees can start work at 8:00 a.m. and leave at 4:00 p.m. Or, employees can start work at 10:00 a.m. and leave at 6:00 p.m.
Encourage or discourage employees taking action?
Following the Pareto Principle, the overwhelming majority of employees will treat work as something they do between 9:00 a.m. and 5:00 p.m. These employees will not make an effort to learn new skills or technology on their own. The remaining 20% of employees will invest their time and energy on learning and improving their knowledge. Companies can decide to either foster employee development or to neglect it.
The following are examples from my work experience of how management treated employees who spoke at conferences.
First company
I was selected to speak at my first technology conference. The conference was Connect.Tech, which is the premier web and mobile development conference in the Southeastern United States.
Within 48 hours of it being announced that I would be speaking at the conference, our director purchased conference tickets for every developer in the department. My director wanted to support me because I had invested my time and effort to master a skill that I would be speaking about at the conference.
Later, after accepting to speak at my second technology conference, the director pointed out that I was speaking again and gave me a monetary reward for my efforts.
Second company
This company was in the process of rewriting their website from PHP to AngularJS. I was selected to speak at ngConf, which is the world’s largest conference on AngularJS.
To speak at this four-day conference, the company required that I take two days of vacation. I was also given two days off. The conference covered my airfare and hotel, but I paid for my own food and taxi rides.
At the last minute, another programmer decided to attend the conference. The company paid for his airfare, conference ticket, hotel, taxi rides, and food. As well, the company gave this guy four days off to attend the conference.
Later, I asked the company if they would also cover my food. They responded by saying that I was being self-centered and just wanted to exploit the company’s resources.
How to avoid it
As you can tell, the company culture in these two companies are drastically different. When you look for a job as a software engineer, make sure you do your research about the company first. Try to figure out whether or not the company invests in their employees’ development. Does the company encourage their employees to improve their skills? Or does the company discourage it?
Work processes and quality control
Quality assurance (QA) is a part of the software development life cycle. QA ensures that there are no bugs in the code. The longer a bug goes undetected, the more costly it is going to be to fix it later on.
Git is the primary tool programmers use for version control. Programmers in a team must have a strategy to control the codes used in production-ready codes.
The following are examples from my work experience. They show when companies invest in their work processes and when they do not.
First company
Every programming team had a QA person. QA was responsible for checking the programmers’ code and verifying that it met the acceptance criteria for the story. If the QA engineer had concerns with the quality of the code, it was the programmer’s responsibility to re-do the code until standards were met.
The programmers used a Version Control System workflow (VCS) to create branches that reflected the number assigned to the story. Once programmers completed their code, they were required to merge the master branch into their code to see if there were any merge conflicts. Once that was done, they submitted their code to the master branch.
Before the end of the sprint, the entire team would spend a day verifying that the code on the master branch met the acceptance criteria for every story. Programmers were required to verify the work completed by others, but were not allowed to test their own code.
Second company
This company did not have a single QA person on staff. They also did not implement a Git workflow strategy. As a result, programmers were responsible for testing their own code in relation to the story, but not in relation to the potential impact it might have on someone else’s code.
A release was pushed to production. The push resulted in the website going down. Luckily, the code was rolled back within seven minutes. In the following week, a team lead and several programmers tried to find a solution for the website outage. For several nights that week, they worked until 10:30 p.m. trying to fix the problem.
After resolving the problem, management sent an email praising the team leader for the hours he spent solving the problem. The email concluded that all employees should be willing to work the same number of hours to complete their work.
Instead of addressing the root problem, which was having an ineffective VCS strategy and a lack of QA resources, management decided to praise someone for the side effect.
How to avoid it
When interviewing with a company, you will probably speak to more than one developer on the team. Ask them if the company utilizes an effective VCS strategy. If so, ask them to explain what it is. It is important to know if all programmers provide a consistent answer to this question.
Another question to ask is what is the time between when an error with a production code is reported and when that error is fixed.
Work-life balance and vacation time
The Business Dictionary defines “work-life balance” as “a comfortable state of equilibrium achieved between an employee’s primary priorities of their employment position and their private lifestyle.”
Programmers should seek a job that does not demand an excessive amount of their time and energy that they miss their children’s birthday or taking their vacation.
The following are examples from my work experience of how management manage their employees’ work-life balance and vacation.
First company
This company provided three weeks of vacation. Employees could take vacation with as little as one day’s notice. There was no problem when one or more employee went on vacation at the same time.
If employees did not take their allotted vacation, it did not roll over to the next year. Between Thanksgiving and Christmas, the company sometimes worked with partial development teams. This is because programmers were sent home to make sure that they used all of their vacation.
Second company
An employee, along with four other couples, scheduled a trip to Hawaii where they had rented a compound on the beach for a week. Shortly before this employee was scheduled to leave for vacation, he was asked to reschedule his vacation. The reason given was that the company had an upcoming deadline, and they were behind on completing it.
When I tried taking time off, my team leader asked me to make sure that our deadlines would not be negatively impacted by my vacation. In other words, the company expected me to schedule my vacation around my work deadlines.
How to avoid it
Ask what benefits the company provides in terms of vacation and holiday. It is important to know if you are able to take time off without giving notice several days or weeks in advance.
During your interview, ask every programmer if they took all of the vacation time they were given, for every year they have worked at the company.
Conclusion
Company culture is a reflection of the leadership and work environment within a company. As a new programmer, working for a company with a positive company culture can catapult your career. If you end up in a company with a negative company culture, it can impact your ability to learn and grow as a software developer.
More articles
Thank you for reading my article. If you like it, please click on the clap icon below so that others will find this article.
Here are more of my articles that you might find interesting:
Subscribe to my newsletter
Read articles from freeCodeCamp directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
freeCodeCamp
freeCodeCamp
Learn to code. Build projects. Earn certifications—All for free.