Teams of people need structure. Humans are imperfect, forgetful, prone to mistakes, and often cut corners for convenience or “time saving”. Yes, structure and organization are important for teams of programmers and software engineers no matter how many times your leaders have declared that you’re an Agile (with a big A) and agile (with a little a) shop.
Ask Questions during Interviews
It’s easy to get swept up in the marketing techniques that a lot of software companies use during the recruiting and interviewing phases. Maybe you’ve been eyeing a particular position for awhile and finally have the opportunity to make it through the on site gauntlet. You may also be desperate for a job for one reason or another. Regardless, it pays off in the end to make sure you’re aware of how the business operates under the hood.
These guidelines are especially important if you’re signing on as a full time employee or with a company whose primary business is something other than writing software. The former because it’s mentally more difficult to give up benefits, vacations, and a consistent salary should you find out that you’re really not enjoying the job. And the latter because businesses that focus on something other than software are notorious for, frankly, not giving a crap about their various IT/software departments.
During the interview phases of your job search, make sure to take time to ask the interviewer your own questions. Many people overlook this part of the interview phase either because they’ve been in the interview process for 6 hours straight and want to go home, or they just don’t care. From personal experience, it’s a mistake to miss out on the only time you’ll be able to get details about the business, the team, and the project that you may be joining.
Define and Enforce Coding Standards
Many times, software shops will discuss their coding standards verbally but eventually get tired of repeating it to new hires. This means that on-boarding processes are abandoned, and new hires are left to come up with their own standards which may or may not conflict with the previous verbal standards. If your shop decides on a set of standards and holds developers to those standards during code reviews, everyone on the team now and in the future will easily acclimate to the various projects across the team’s code base. This reduces friction and increases coding efficiency.
Examples of what should be standardized include:
- Comment styles and lengths
- Names for projects, assemblies, classes, interfaces, and variables
- Project architectures and structures depending on needs
- Endpoint names and structures in APIs
This list above is definitely not exhaustive, and I’m certain that you could come up with a lot more to standardize. Remember not to go overboard. You don’t want to inflict too much regulation and pains on your teams to the point that they feel incapacitated.
Code Reviews and QA Standards
Reviewing what has been checked in and what is slated to be deployed are two very important and often overlooked aspects of software engineering.… Read more