As I transition now into a new job I’ve been reflecting about the people I’ve met and the things I’ve learned. I’ve met a lot of smart people, and also met a lot of terrible people.

I promised myself to learn not just software engineering principles and programming, but the process by which we create these great things on what has come to be known as the Internet of Things. To reflect on the things I’ve learned I will do a blog series on my time there called “A Culture of Incompetence.” This is Part 1.

Hiring and Mentoring New Developers

This issue is particularly interesting to me – the idea of building a team is exciting! You know that scene in the movies where a guy gets a difficult mission and he says, “I’ll do it on one condition: I get to use my own team. These are people I trust.” Building a team isn’t about slapping people together with the right resumes. People will likely need to grow to fill the position you’re hiring them for. This means a lot of checking in, mentoring, and training them to do things the way a well-oiled machine does.

“I’m looking for people who are willing to work long hours – basically for free.”– A Previous Manager

There I was thinking about new team members when one of my managers says to me, “I’m looking for people who are willing to work long hours basically for free.” … yeah, he just said that to my face. It’s true, anyone building a team has constraints, a budget, and I get that, but telling members of your team that you’re looking for indentured servants is not a good look. The funny thing was, he wasn’t kidding. That particular company hired many foreign nationals and sponsored their H1B visas. By being the sponsor company, there’s a certain power dynamic at play when these employees ask for time off, a salary or performance review, or even when asking not to work overtime.

I do believe there’s an untapped pool of very talented individuals who need sponsorship. Turning over every rock to build a team is commendable, but it’s all in how you go about it. In my opinion this approach was unethical. It was the deliberate choice of a lazy management team that wanted to lower costs by hiring cheaper labor instead of developing an efficient process.

Ok, we’ve assembled a team of wage slaves, who have little choice but to come to work every day. Now what do we do? Well, naturally we let them do whatever they want and do nothing about it. One issue in particular that I came into contact with: some teams were not even committing their code to our version control system.

Had some fun with this particular issue recently. "FTP the latest stuff from production if you want it." Hmmkay 😡 https://t.co/Oe4pzHIPoh

— Bones Jones (@Gutzman) April 30, 2015

We have whole teams of people, working on client projects that aren’t in version control. Before we get into the cost of a “mishap” related to losing code, let’s discuss what could have caused this situation. Have we made it clear that committing working code regularly is an operational priority? Yes. Do we have hundreds of projects already under version control? Yes. Do we have people available to help if someone doesn’t know what they’re doing? Well, kind of.

I have my own team, we discuss software engineering as a practice. I strive to identify weaknesses in my team and to eradicate them through mentoring and training. This type of mentoring is different for every team member – some need hands-on, some need to see code samples, some you need to light a fire under their ass. Why do I do all this… because I decided I was tired of working with a bunch of apathetic new hires, who really don’t care about anything but lunch and going home. It’s also rewarding to see these people turn into up-and-comers.

When I found out that other teams and their members didn’t bother committing code and were positively cavalier about it, I approached my manager. “Well, it’s ok, that’s just how that person works.” Really? REALLY?! Is that how you build a strong team? This is exactly the type of attitude that has pervaded my places of work in the past. It’s disgusting.

Here we have a management team that is assembling resources as cheaply as it can, and then not taking the time or energy to train them up. I believe this culture of incompetence comes from the top and has trickled its way down. It’s exhausting to deal with, it’s exhausting to work against.

Anyway, those are some observations of my current employer’s hiring and training practices. These are things I need to think about and learn from. That’s it for Part 1… until next time.