A couple of weeks ago I attended the second edition of Ruby Unconference London, organized by Codescrum and hosted by Carwow. It was themed “The love for Ruby and all things related to Ruby (Elixir, Crystal) and current trends.“ Read my impressions and some of the points I took away.
The format was simple and included workshops + unstructured discussions around set topics. The organizers suggested the following topics:
- Rails Security and Continuous Integration/Delivery
- Gem authorship & war stories
- How to structure large Ruby/Rails projects effectively
- Opal (Ruby to JavaScript Compiler)
- DDD (Domain Driven Design)
- Alternative Ruby runtimes (TruffleRuby and JRuby)
- Ruby 3 & Rails 5
- Machine Learning/Artificial Intelligence
- Work related: careers/ contracting/ remote work advice.
In the end, the sessions line-up looked like this:
As you can see, at any given time there were sessions on 6 different topics. Each person could choose which one they wanted to join. I took part in a few of them and the ones I enjoyed most were: the one on Hiring, the one about Onboarding Junior Developers, Elixir + Phoenix vs Ruby + Rails, Rails 4 -> Rails 5 and Python vs Ruby. Overall I feel they were all nice and informative.
Elixir + Phoenix vs. Ruby + Rails
The main topic was the use of these technologies (advantages and disadvantages) especially in the context of building a chat bot but also working with them in general. Other technologies such as Crystal and Erlang came up during the discussion. Main takeaways:
Ruby is friendly for beginners, fast to develop and good for startups
Rails has a good gems ecosystem and a great community
Elixir is almost 10 times cheaper (for data storage) and 10 times faster
Crystal might be an alternative to Ruby (it has improved performance) although it’s pretty cumbersome to work with
Erlang is potentially an alternative for Elixir and it’s perfect for distributed, high availability, fault-tolerant applications (currently used by WhatsApp)
Onboarding Junior Developers
This was a pretty popular session, run by Dan Garland. He’s the CEO of We Got Coders, a development consultancy / code bootcamp / recruitment business. If you want to find out more about them, especially if you are hiring junior developers in London/UK, check them them out here. Dan started by talking about the pros and cons of hiring junior devs, then pitched We Got Coders very nicely. The main takeaways from this session:
- Problem solving abilities are more important than knowing specific tools, look for that when hiring / assessing junior devs
- Don’t ask for too much on job descriptions (specifics will put good people off from applying)
- Best way to assess candidates instead of technical tests is to try them out: ask them to work on one of your side projects, see how they perform
- Retain people for more than a few months by giving them training and coaching, then show them how they can make an impact at your company
- When facing a problem, tell them which approach you would use to solve it, don’t show them step by step how to do it; start them off on the solution then leave them to do main part of the work (this helps cement their learning)
- Encourage them to ask questions (remember to make it clear that there’s no such thing as a stupid question)
Hiring
One of the most popular sessions of the day. A lot of people were interested in this and took part in the discussion, including Carwow’s technical recruiter and some of their engineers. Broadly speaking, the discussion was focused on 3 key areas: general recruitment issues, job descriptions and candidate assessment. Here are the main points that came up (and my thoughts on some of them):
1. General recruitment issues
Many companies are struggling to get direct applications from good candidates — definitely something I’m familiar with, as most of the companies that need our help are in a similar situation. I think that working with an external recruiter can help you get an influx of qualified candidates, however companies should also consider improving the quality their job ads and making their company culture more transparent
It’s easy to find good developers from the technical point of view, but hard to find those that also match company culture — as mentioned before, I think it’s important to define your company culture and make it transparent so that the right people will be attracted
Companies should boost their recruitment efforts by making themselves more visible: try to convince each developer to write blog post (Ruby weekly, PostgreSQL weekly, etc) and mention the blog posts in your the job descriptions
Many experienced developers apply for a job and get a reply only after couple of months — Companies deal with many applicants, but surely it’s worth trying harder to identify the promising applications and reply within a few days?
2. Job descriptions
You can really turn people off with a badly written JD. For example, maxims such as Exceptional, Outstanding and others like that can easily discourage good people to apply for your jobs
Job descriptions should mention small benefits, such as the ability to leave the office for half hour in case you need to pick up something from the pharmacy — I’m not sure this is such a good idea, as the JD could become very long very quick if companies list every single small perk
Job ads and job descriptions are not the same, use job ads to tell a story — I totally agree with this point and frankly don’t understand why so many companies miss this opportunity
3. Candidate assessment
- During interviews, don’t try to catch people doing something wrong, it gives a wrong and negative impression about working at your company
- Assess culture by asking questions such as: “would you make a colleague a cup of coffee?”
- Optimise your technical tests. Typical scenario: the CTO creates a test (based on their 10 years of experience) and expects mid-level devs to be able to complete it within 2 hours
- Test idea: Get someone to TDD a checkout written in Ruby
- Best assessment: organise a pair programing session (maybe combined with reviewing the candidate’s Github account)
- One of the last sessions of the day was called Talking about Talking, led by a guy called Tom. I didn’t attend, only heard about it from others. Apparently Tom convinced most attendees that they want to give a talk or a presentation, even if they were sure they didn’t. Tom also told them something like this: “Keep in mind that each talk you give will literally change the world. People will take new ideas from it., new courses of action, which in turn will influence other people to adopt new ideas and take new courses of action. Remember to do proper research for your talk and prepare your slides with this in mind.”
Final thoughts
I was surprised to see very modest activity on social media during the event. The official hashtag on Twitter was #lrun, but there were only a few tweets sent out on the day mentioning it. I was expecting more buzz, considering the number of people that attended and the relevance of the topics.
I feel that some of the moderators could have stepped in more during the discussions. On a few sessions there were long pauses and the discussion seemed stuck. I noticed a couple of attendees that wanted to contribute more, but they were not encouraged enough to do so.
Overall, it was a cool event. I met interesting people and learned more about each of these topics. I managed to take away a lot of interesting ideas and will seriously consider attending next year as well. If you are a software developer with interest in Ruby and the other technologies mentioned above, or part of a company that is hiring them, you should consider attending as well. For updates on next year’s event be sure to follow Codescrum here.
