Cleaner Code

Getting back into the world with vaccines and re-openings, I've had a chance to sit down with some folks in the same industry and just chat. Exchanging stories about engineering, hiring and finding folks to grow a team and wanted to blog about those thoughts.

Code

Year after year my perception of clean code evolves and changes, but one thing that I've come to appreciate is consistency. For example, the pure arguments about code styling is beyond annoying. Thankfully some languages these days even have syntax formatting baked into the tool itself.

I've learned that automation and enforcement is the friend here. New employees can't argue with a red x on their change request if a robot is telling you it does not validate as proper formatting.

Though, moving on from formatting to the framework's themselves. I once spent time in a Laravel project that followed next to zero of the Laravel conventions. I can only guess that the previous employer to this project expected Laravel and the team delivered without knowing it.

It should be in the best interest of any development team to follow the conventions and opinions of a framework so churn in a team does not affect the things that don't matter. Time in a code base should be spent on what really matters - the true secret sauce that makes the project exist. When you are doing custom work against the norm for things that are just given by a tool or framework - the barrier to entry for new folks just rises and that slows you down.

Environments

With every line of code written an environment needs to exist to run it. For some their life is Java, which has its own fair share of complexities running as compared to PHP. Either way though, if you heavily work in a language and don't understand how it runs outside of a development environment - that is something to pick up.

For the majority of folks I'd bet that environment is not Windows. Become comfortable on the terminal - learn the hundreds of little tools that excel at 1 thing a piece. So the next time there is an issue on a server with a project you helped develop you feel confident with understanding the stack to diagnose the issue.

I remember asking someone to grep a log file to look for a certain phrase and left with a stumbling stare. It isn't hard to learn if you give it a chance.

Personality

If you write code with the intention to make it so complex that only you understand it - that's a problem. I think the perfect code is something that is understandable and solves the problem that a new employee walking in on day 1 can also understand.

On that same path - if an issue occurs and you are first to point fingers vs lending a hand - that's a problem. Coworkers should be working together to solve issues and create software - not fighting against each other.

Team

As you look for someone to join your workplace, I think a cultural fit among a team is just as important, if not more, than technical skills. Technologies can be taught, but generally at the age of finding employment behavior is a long slow process to correct. So if you are near the point of picking up a new hire - take them to lunch. Watch how they interact with the staff, that is the greatest tell tale sign of how someone treats other people.

You don't want someone that emits toxicity or treats others badly. You'll notice pretty quickly how that affects the productivity and turnover of a team with one of these folks.

With that, just some thoughts about the workplace.