This week my family and I booked a holiday. After much discussion, research and reading Tripadvisor, we are off to Mexico. As it is 2018 you might think that I booked the trip online. You’d be wrong. We ended up booking with a travel agent. This was due to some additions that we wanted to make and a room we wanted that wasn’t offered by a UK online company.
In the UK there are becoming fewer and fewer actual travel agents to go and book a holiday with. I am not going to name and shame the company that I booked with. They offered mediocre customer service. But, the thing that stood out as I endured a near 90-minute booking experience was the poor use of technology.
When we arrived we sat down with the agent. The first thing they did was to bring up the holiday in one browser that we had found on their online site. In another browser, they then logged into an internal version of the company website. They then pulled out a paper notepad and started to scribble various references down. They started to write down the online and in-store prices. Then, on paper, they started to work out any discounts they would be able to offer. Their internal site was pricing the holiday at over £1000 more.
It then descended to a point where they had to log in to over 6 online systems. These covered the online and in-store versions of the company website, insurance website, payment system, airport parking and excursion websites. The thing that really stood out was that as the agent logged into more systems the use of the paper notepad grew. Each piece of data required by the payment system was written on the pad before manual entry. When various product shortcodes were required they were obtained from a printed sheet.
Security was worrying. On a couple of occasions, they shouted out to a colleague for a password. The response was then written on the notepad. It would seem that for at least one system there was a shared login. The scariest thing of all was the notepad paper being scrunched up at the end of the process and being thrown in a trash bin.
There was so much that made me take note. Why does this company have an internal and external website for their holidays? Why not have one that lists both prices. Why make the agents calculate the discounts when you have the data sitting on a server? Why is the payment system separate from the holiday data? Why is there no integration? Why not integrate with your partner’s for insurance and extras? So many why’s.
The agent took 90 minutes to book the holiday for a few hundred pounds more than the online price. In the time we sat there the staff lost 4 potential customers because all the agents were busy. What could the impact be on that business if they integrated their systems? How much quicker could they book a trip for a customer if there was no writing prices and references down? What if they could halve the time it takes to book a trip and match the online price? I am guessing fewer mistakes, happier staff, much happier customers and more revenue. By allowing their technology to remain so disjointed they are harming their business.
Have you worked for a company that does not realise the danger of disjointed technology or seen it in action recently? Message me via twitter or email.
When starting any coding project you should use Version Control software. Used to track changes to your code this software also allows for many people to work on the code at once. It may seem overkill but these systems provide a safety net for even the smallest shell script.
While there are many options out there, the most popular option is Git. Originally developed by Linus Torvalds the software quickly gained fans in the Linux Kernel community. Open sourced and released under a GNU licence, a community of developers and tools grew around the software. Github, a service designed to simplify the process of working with Git has also helped its growth.
There are many good tutorials for learning how to use Git such as:
The issue I want to address is when you start a project that has the potential to grow fluently. It is easy to work with Git by branching off of master and doing some work and then merging it back in. In fact, there are a lot of very large companies that do just that. But, if you’re a small company with limited resources it is hard to track release and development branches. If you use a centralised service such as Github or Bitbucket they offer integrations. For example, these integrations will allow you to automate your deployments via Git. They may also hook into your work management software such as Jira. Given that complexity grows in line with the number of branches, what you need is a workflow that brings some order.
Gitflow is not new. In fact, the article referenced above dates back to 2010. Gitflow specifies a way of setting up your Git repo and working with the branches. Its aim is to segment working code from development code. It allows developers to isolate features in development away from testing. Once tested the code can then be pushed to Production.
Within the workflow there are 4 main branches:
Master - This is your production code. The code on this branch should always be working, tested and deployable. No development changes should never be merged here directly.
Develop - This is your developers currently building code. Think of it as the master branch for development. Feature branches are pulled and merged to develop.
Release - The release branches are pulled from your develop branch and merged into the master and develop branches. The branches live for as long as you need to test the code/features within them.
Hotfix - These branches are pulled and merged from the master branch and are used for performing small bug fixes in your production code.
This set up gives you a lot of flexibility. You can have a team of developers working through your features for a sprint at the end of which you create a release branch. That branch is released to your staging site. While being tested your developers move on to their next work. Oh, wait, someone found a bug in the release branch and one of your developers fixed it. That fix lives in the release branch until the testing is complete. A couple of days later the testing is completed and the release branch is merged back to the develop branch. This means that the fix that was made is retained. The release branch is also merged to master and pushed to your production site. All the while this was happening multiple feature branches have been created, reviewed and merged by the developers. But, it is easy to track what is going on, which is the power of the workflow.
Gitflow is adaptable to your DevOps workflow as well. For example, at Open Energy Market we have Azure hooked up to our master branch. We have a Staging branch set up which our Azure Staging environment connects to. When commits are pushed to either branch it triggers an automatic build and deployment. Due to some of the bigger features, we have been working on of late, we have been able to manage many release branches with ease.
Gitflow’s popularity has lead to its adoption in many tools such as the Source Tree and Git Kraken GUI’s. There are also many console-based implementations, the best of which is nvie/gitflow.
There are other workflows available for Git. From my experience, Gitflow is ideally suited to small teams with limited resources. Once you have your development process then Gitflow is a great supporting process.
Have you used Gitflow for a major project? Are there better workflows for your usage? Message me via twitter or email.
About 9 months ago I wrote some advice for candidates based on reading a lot of CV’s. We are hiring again at Open Energy Market and I have carried out many interviews over the last month. A couple of stand out candidates made the process engaging and fun. Most didn’t for a variety of reasons. So I thought I would share, publicly, some feedback.
Research the company
When interviewing for a company it is rude to know nothing about it. Every company has a website, files accounts or registers with professional bodies. The information available varies. But, you should be able to answer the question “What do you know about our company?” The answer should also be better than “You work in industry x” and should prove effort on your part. You should be able to provide evidence that you have done your research in your answer. Who does the company work with, what is the company vision, how are they different from their competitors.
Just to be clear “Not a lot really” or “Nothing” are unacceptable answers. (Both of which were provided during the latest interviews).
Research the role
You will have a job description for the role. Use it to prepare.
Prepare to answer questions about the technology stack used. Your knowledge of that technology will be interrogated. Brush up on any parts you use less often. Prepare to answer questions about the technology’s ecosystem and architecture pro’s and con’s.
Have examples of how you have solved problems using the technology stack. It can sometimes be useful to have code snippets. These can act as conversation starters. I expect candidates to explain how their experience is relevant to my role. Be honest. If you have tried solutions that haven’t worked as expected, share and be clear on how you overcome the issues.
There is nothing worse than asking a candidate a question and getting yes/no answers. A good candidate will engage in a conversation about technology and share opinions.
You are not an island
When discussing a technology or library, the answer “I have my own version that is better than x” is usually a red flag.
Why do you think your framework is better than Bootstrap? Why is your ORM better than EF or Dapper? What makes you better than an open source community or a corporate development team. Obviously, this should be applied on a case by case basis. But, it tells a lot about a developer who makes that kind of statement.
(FYI if you are Linus Torvalds, Guido Van Rossum, John Resig or DHH this section probably doesn’t apply to you.)
For a recent role, we interviewed two candidates at the polar ends of a long spectrum. One candidate took 22 minutes to introduce themselves and provide a “brief” career history. They literally didn’t take a breath. The very next candidate was the opposite. They said nothing more than the very least they could get away with.
There is a middle ground. Answer questions in a considered and detailed manner but do not bore people. Remember that the interviewer will want to know how relevant you are to the role. Being told about your paper round is of no value. If you do not know an answer then be honest and do not stumble to a bad answer.
Developers like flamewars and arguments. They are by nature opinionated people with strong views about everything technical.
Be flexible in the discussion. Don’t forget that interviews should be a two-way process. If you disagree with a statement or opinion of the interviewer, then counter. Do so in an educated manner and provide context for your opinion. The interviewer may even throw a curve ball question in to see how you react.
If something is a deal breaker for you then wrap the interview up there and then in a professional manner.
Keep it calm and polite.
Have a working environment
At Open Energy Market we carry out interviews via Hangouts. The main reason we do this is that our development team is fully remote. That means that candidates should be comfortable with video calls. It is the main method of daily communication. Doing interviews this way proves a candidate can be comfortable working in this way.
If a candidate takes 15 minutes to sort out their sound or video issues it’s a black mark. Hangouts is not a cutting-edge new technology. It is extremely easy to set up and if you are attending an interview using it you should be tested and ready to go.
A recent candidate was unable to operate Hangouts at all. Instead, they invited us to use their existing employers Skype for Business service. Not a good impression.
So, that is a brief summary of advice from 20 or so interviews. Every interviewer is different and the approach taken varies on the role. However, if you are prepared and can calmly and clearly explain how your skills and experience fit the role requirements you will standard a fair chance.
If you have any comments or would like to discuss this topic further then please message me via twitter or email.
This is a great validation of the work we have done at Open Energy Market over the last 5 years. The technology we have built has already changed the corporate energy market. Using the investment to enhance our technology further we have some exciting plans for both buyers and suppliers. I am looking forward to the next phase for Open Energy Market.
Recently I wrote about switching my hosting away from AWS over to Netlify. As part of the process, I also moved my DNS records over to Netlify. This process was painless but in the euphoria of such easy deployment, I forgot all about my mail records.
I use Hover as my domain host and use their email forwarding service on a selection of addresses. After a couple of days, I noticed these addresses were no longer being forwarded and I felt like an idiot!
After I berated myself, I set about looking at how I managed to get the MX records added to Netlify’s Domain zone records. To be honest it was harder than it should have been. Mainly down to the non-complete documentation from Netlify. They make reference to being able to do it but for the less inclined it was not at all clear.
So this is how you add your email (MX) related records to Netlify:
Login to Netlify and head to the Domain Settings section for your site.
Scroll to the bottom of the page and look for the new DNS zones section. At the time of writing, it looked like this.
Select the zone relating to your domain.
Click the Add new record button and enter the settings.
The settings are as follows:
Type - MX.
Hostname - Will default to the name of your Netlify site name.
Value - This should be the server path for your email service. Do not include http:// or htpps://
TTL - This is the Time To Live setting for the record. The standard Netlify setting appears to be 3600 but I tend to set short TTL’s where possible.
Priority - This should be set to 10 from what I can ascertain.
Click the Save button and wait for between 15 and 30 minutes for the settings to propagate. Your email services should be working as before.
If you have any comments or would like to discuss this topic further then please message me via twitter or email.