1) For those of you who don’t know you, can you please introduce yourself and your company
Hey ! I’m James Rose. Me and my business partner Mark run a few businesses. The “parent” one is Aktura Technology and our new focus is Content Snare.
Aktura builds web based applications and software for a variety of businesses, but our sweet spot tends to be accountants and start-ups. Content Snare is our new SaaS product. It’s made for web designers and developers.
It helps them get content from their clients without the hassle. This has consistently been a massive pain in the butt for us, so we’re trying to fix that for us and everyone else in this space.
2) What is your particular background? How did you get into Web Development
Right out of university I went into control systems engineering (also called automation). In human-speak, that means making machinery easier to operate or making it operate by itself.
It’s the interface between man and machine. It involves a lot of coding in languages most people aren’t familiar with – ladder logic and function block diagrams. In 2008 during the “Adsense goldrush”, you could make crappy websites with a few ads, rank them in Google and make a few bucks on the side.
I learned about this and started building sites myself. I spoke about this at my day job and a workmate joined in. We were using a tactic called ‘article spinning’ to generate links for SEO. At the time, all the software in that space sucked, big time. We decided we could do it better and started a company not long after. That began a 6-month slog of learning C# mostly from Stack Overflow (haha).
Towards the end of my day job, I was asked to build a couple of web apps. I used that as an excuse to learn ASP MVC for the first, and Ruby on Rails for the second. After a few years of that, we ended up building WordPress websites for local businesses after being asked by a few people who mistakenly thought that’s what we did.
3) What courses/resources/websites did you use to become a proficient web developer?
Honestly I think self teaching is one of the best ways. Just by trying to build *something*. You can go through courses and learn some basics – I still think that is a good idea – but you learn the hard stuff by going “I need to do this thing… but I don’t know how to make it work… let’s find out”. That means a lot of help from Mr. Google and Stack Overflow, plus trial and error.
That said, I think one of the biggest things is knowing what’s already available to you in existing frameworks. For example, in my early C# days, I spent a week building a fast lookup system for words in a thesaurus. Then I learned about the “Dictionary” class built into .NET which did it 100 times better than I did and required a couple of lines of code.
There are SO many things baked right into frameworks like .NET or Ruby on Rails. Or code that’s already been written that you can drop in, like the gem system in Rails. It helps to be across those kind of things I think. If you’re looking for quick starts, I think Code Academy and Treehouse are good places to start. It depends on the language though. I read a massive Ruby book back to back first to understand how the language worked. But then you just have to start trying to make something.
4) What kind of people do you look for when hiring? What skills / personality traits
This is so hard. We’ve not yet found a reliable way to know if someone will be good before they start. I don’t think anyone has.
Having a trial period is a good idea – a period where you get someone to do a specific feature in a new branch, and see how they build it. See how they work with you. If your gut says no, it’s probably right and you should get rid of them. My gut feeling has rarely been wrong – I see that with a lot of other people too.
For specific traits, they definitely have to be a problem solver. Someone who will go and find a solution or two before coming back to you with the problem. Someone who’ll say “This is the problem. I’ve found these ways to make it work. This one will take 2 weeks more, but I think in the long term it’s better because…”
They also have to be good at communicating when something has bogged them down or is causing problems. It’s so frustrating when someone tells you they’ve been stuck on something for a few days and haven’t told you until now.
5) What are some of the issues that you come up against with your own clients and how to do you solve them?
It’s almost always expectation management. Some clients think that they can give you 2 dot points and you can go away and create some huge app from that.
We need to get better at communicating that their part in this doesn’t end when they sign the contract – they’ll need to commit time to going through feature development and requirements with us. We’re not mind readers, but I think a lot of clients expect that, without realising that is what they’re doing.
But regular communication is the resolution to that, at least in most cases. Some clients are lost causes, and you just have to cut those ones. For the others, if you can get them involved in your project management system they can see everything going on, and I think that helps.
We invite our bigger clients into Jira where they can provide feedback on issues. Some clients just flat out refuse learning a new system though. The other big issue is not understanding how much custom development costs. If they don’t have the budget, it’s probably not a good idea to try to work with them unless there will be some other kind of benefit – like an amazing case study or flow on work. We’ve been burned by low budgets way too many times.
6) We just ourselves registered for https://contentsnare.com/, can you tell us how it came about
I’ve just started a video series on this actually. Before custom dev, we built basic WordPress websites as well.
I have an unhealthy obsession with automation, and found that so many parts of the web design process just sucked from that perspective. At first I had this idea to automate the briefing process. I lined up about 15 calls with potential clients (other web designers) through my local network and some online forums, and just asked about their process from getting a lead through to handing the website over at the end.
I tried not to ask leading questions, and just see where the frustrations came through in their voices, and probed further into those parts. Almost all of them ended up hating on the content gathering part of the website build. Real frustration was coming through. That’s where it all started. Then we build a landing page and started promoting the idea. The reception was epic. Now we’re just trying to make it work well and make sure it solves the problem for people.
7) What are the main technologies you used for the frontend and the backend?
Angular2 and Rails API.
8) Why did your selection end up on these technologies?
To be honest, I’m no longer the tech guy. It’s all handled by Mark. But he’s the kind of guy that is absolutely meticulous in his research. He played around with ng2 for weeks before deciding it was super powerful and that we should use it.
He’s spoken about the modularity of components a few times which sounds like a big plus. As for Rails API – we already had the team for that. I don’t think the back end is as important as it used to be. You can choose just about anything major these days.
9) Can you tell us a bit about your development cycles, in regards to adding and testing new features/versions?
Mark has put a ton of work into this. He’s created workflows in Jira that automate as much as possible, so that the process must be adhered to. I’ll do my best to describe how it works, but bear in mind I’m not to deep into this side any more.
Before Jira, we have a Google Spreadsheet with features prioritised. We pick out the ones that will definitely be developed and put them in Jira, into the backlog. For each cycle, they are moved into to-do and assigned.
The devs create their new branch and work on the code. There’s an automated code quality test, then a peer review before it gets rolled into staging. The new features are tested and accepted on staging, and then are rolled into master. We run a similar process with client work as well.
10) From a technical perspective, did you learn any important lessons, good and bad, that you’d like to pass on to other upcoming developers?
I think I covered most of what I’d say here in the hiring and learning sections. Also, if you’re the kind of person who worries about if they’ve picked the wrong technology to work with, probably stop worrying. It’s just not worth it.
Stick two a major front end framework and a major back end one, provided you like it. Just get really bloody good at those. Every framework has lovers and haters. As long as it works for you, you’re good.
Oh and do your research when applying for jobs. When someone says something that shows they’ve researched me or our business, it stands out *so much* in the pile of applications that we get.
