A Talent Point of View: Building a TePe(DeBe)
Working for yourself... it's great isn't it? The dream.
I wouldn't know, I'm afraid. I've worked for someone my whole life. I don't mind it, though. It's nice to have that level of security around your next pay-check. It's nice to go on holiday without biting your nails and checking your emails every hour to make sure your baby is ticking over in your absence.
But I've had a little taste of that life recently. Not my own business, but a software project for which I am directly responsible. Don't get me wrong, I'm not on my own here. There is a talented and hardworking team, each member working on their own parts of the larger whole. But, for the back-end at least, the buck stops with me, and that's both vaguely terrifying and, also, a little bit great.
First, though, a brief history: I've been working at Talent Point for over 2 years, largely in the capacity of Technical Writer with a little miscellaneous developing on the side. Last year I built Bridgey, a simple but mostly effective way for our Talent Managers to quickly input potential applicants into our CRM. The point was to encourage the team to enter the information "our way"; the Talent Point process has been designed very specifically, tailored to how we source applicants and make placements, and no off-the-shelf solution quite worked for us.
As with many software projects, completing Bridgey gave us a tantalising glimpse of what might be possible. The potential for automating or augmenting our process even more comprehensively – perhaps incorporating the whole life cycle, from campaign request, to interview, to placement – suddenly presented itself. So, with Bridgey as our template, we began on a much bigger software project, which came to be known as TePeDeBe (as in, Talent Point DataBase). Naming software projects has never been our strong point.
TePeDeBe is, in theory, the backbone for all our software projects going forward, and in reality it is also, without a doubt, the most complex thing I have ever built. At its core, TePeDeBe is simply a database storing all aspects of the Talent Point structure: users (defined further by role – inheritance, baby!), pods (the basic building block of our team structure) and companies (our customers). The links between these can get a little involved: for instance, a company has an Account Manager, who has a pod, which has an Account Director, who has a Delivery Director; therefore, implicitly, a company has a Delivery Director!
Each user, company or pod - and their relative links - should be served up via an API so it can be used in other Talent Point projects. Oh, and the user class should double as authentication, so that the whole system can be used as a sign-in system for said projects, for our whole staff.
Laying the Rails
Luckily, Rails gives us a lot of this out the box. The ActiveRecord ORM allows you to setup complicated relationships quite easily, and the Knock gem is great for authentication. It allows easy passing of JWT tokens (yes, technically a tautology, but JWT on its own sounds weird) between client and server, authenticating users of the API quickly and easily. Quality gems like this one are really what make Ruby (and Rails) great.
So all this built-in/plug-in functionality allowed me to get off to a flying start, but I was determined to slow down and do things right. When working on your own, the temptation is to fling a load of code at the wall, and promise to yourself you'll setup tests later. But, as I'd never worked on a database of this size and complexity, I forced myself to slow down and work, at least in part, with TDD. And I'm glad I did, because it made the whole thing a lot easier.
I'd always planned to just use ActiveAdmin as an ad hoc front-end to TePeDeBe - no point in making something if there already exists an out-of-the-box solution. Unfortunately, when using Single Table Inheritance (which I had for a lot of the user roles), ActiveAdmin gets extremely complex to setup. It has its own DSL around relationships and views, and it started to get real sticky, real quick. So I decided it would be easier to build my own front-end.
We'd already decided that for our projects going forward, React was going to be our framework of choice, specifically using the create-react-app. We had a decent supply of knowledge in-house in the form of Will, account-manager-turned-front-end-whizz, so I knew if I got too stuck, there would be someone to talk to. He may even write his side of the story in a follow-up blog post, who knows. If he ever does, I'll hyperlink this piece of text right here.
React is a funny one. People who have used it, learnt it and lived with it have a habit of thinking it's the easiest thing in the whole world, but when you're without experience, it really can be quite daunting. At its very essence, it's just a way to a) programmatically create HTML, hence beautifully reusable components (in theory) and b) manage all your state, for seamless data-fetching/sending to an API (in theory). It all sounds great (in theory), but all this beauty comes with a learning curve.
That said, I knew this simple front-end really only had to be robust enough to add our staff members to a database once and then maybe edit them if someone got a promotion... surely it couldn't be too hard?
This ‘simple front-end’ probably took up more time than the rest of the project combined. Oh, and there are no tests. Please don't look at the React code, thanks!
I think the biggest problem throughout was simply a lack of Seniors. In any normal-sized software development house I, a Mid-level Developer (ish), would be allowed to happily code along, picking up tickets and ensuring they passed acceptance criteria. When I got stuck, someone would always be there; when I was unsure about best practices, someone could show me the right way.
But at Talent Point, we don't have any Seniors, so instead I relied a lot on Stack Overflow. Whilst undoubtedly an invaluable service, SO is also like a stubborn magic genie: it will give you what you ask for, but not what you need. It's all about asking the right questions. Only very rarely will someone say: "here is what you are trying to do... but WHY on earth are you doing it like this?" This is what Seniors give you.
Still, we got there, and TePeDeBe – along with its symbiotic use-case, Hubby (designed and built by the aforementioned Will and, yes, we can't name software projects, we've talked about this) – are launching next week. I'm really proud of it. And really, it's very much only the beginning. The backbone is now in place... let’s see if we can make the rest of the skeleton.
Our "super-professional" Git commit record for TePeDeBe!