-
- 22 Apr 2016
- The "D" word
+ Multitenancy with Rails 2nd Edition
+ 22 May 2016
+ Multitenancy with Rails 2nd edition is now "content complete". I have now finished doing the majority of the work on this book and all that is left is to go through it and "proof" it.
-We have a diversity problem in the community, and that's been talked about
-quite a lot when it comes to tangible things like gender and race. A
-diversity of skill -- an intangible thing -- is also something we talk about
-struggling with.
+The book has been updated for Rails 4.2 and uses industry best practices of
+building a multitenanted Rails application, and the best practices of using
+Braintree or Stripe to add subscription features to that application.
-When I started out as a Rails developer, I was tinkering around with the
-framework in my spare time, which I had a lot of because I was single and
-working casually at Coles and doing the odd spot of PHP/Rails freelancing.
+If you've read Rails 4 in Action or something of a
+similar level to that, this book is a perfect "next step" for you. It adds
+features which are more complicated than a basic "CRUD" app to an existing
+codebase. If that appeals to you, use the coupon code "fin" to get 50% off.
-I heard that there was a Ruby meetup happening in Adelaide and I caught the
-train into town and ran to the meetup because I was running very late.
+This update has been quite a long time coming: it took me 298 days from when I
+started updating Chapter 1 to this current point. Next up, I'll go through the
+book and make sure there's as few bugs and typos as possible. Once I'm done
+with that, then I will consider the book to be complete.
-When I got there, people asked what I did and I told them about Coles, PHP and
-Rails. They said "you don't need to work for Coles anymore" and three people
-gave me their business cards and said I should apply for a job. I applied for
-a job at SeaLink and was accepted.
-
-At SeaLink, I got mentored by a team of "senior" Rails developers who had a
-whole bunch of patience for my 19-year-old antics. I am very thankful to them
-for the time that they spent mentoring me, as I believe it helped provide a
-foundation for a career that I've been doing for very close to 10 years.
-
-There are plenty of juniors at the Melbourne Ruby Meetup. I know because I
-help run the Hack Night where a lot of them attend also. If a junior from this
-meetup was to tell you that they were actively looking for a job right now,
-would you hire them? Probably not. There seems to be quite an aversion to
-hiring juniors, and the main aversion is that juniors take up valuable shipping
-time with mentoring time instead.
-
-In the early days, there was a lack of available talent and so companies had
-to hire whoever they could find. That's why I found it easy to get a Rails job
-back then. I think we have once again reached that point where there just
-isn't any talent to hire.
-
-I've been having a lot of discussions recently in the Ruby community about why
-companies seem to be shying away from hiring juniors. Instead, these companies
-want to hire mid-to-senior developers and do not want to have apprentices who
-are learning alongside those mid-to-senior developers.
-
-Lawyers, mechanics and plenty of other professions have apprenticeships, so
-why don't programmers? It's pretty strange. I think it's because those
-professions have had turnover in their companies enough to learn the lesson
-about training for the future. This is still a young community where most
-people have been doing it for less than 15 years. We need to think long term
-about this: who will look after our code when we're gone?
-
-Hiring seniors
-
-Let's look at why companies want to hire mid-seniors in the first place. At
-the companies I've worked at, we've wanted to hire a new mid-to-senior person
-because our workload has gotten to the point where it's exceeding our
-capacity. I figure that this is the same at other companies too. Like where
-I've worked -- and currently work -- you'll have people breathing down
-your neck asking when bugs are going to be fixed or new features are going to
-be developed.
-
-To address this problem, you hire a new developer or rather: you try to hire a
-new developer. You want a mid-to-senior developer because they have the
-skills to instantly dive straight into your application with little-to-no
-guidance and they can start shipping code.
-
-However: the trick is finding someone who's available at the moment. In this
-current climate, it's nearly impossible to hire a mid-to-senior Ruby developer
-to come work for your company. What typically happens is that developers get
-aggressively poached between companies.
-
-Companies spend thousands of dollars on recruiters and lots of time posting to
-job boards, for often very little good return. Companies spend this money to
-hunt the elusive 10x Developer Rockstar Unicorns, but the Unicorns are no
-longer out grazing in the sunny meadows, readily available for capture.
-They're already working somewhere else and the conditions of where they work
-are extremely good.
-
-We, as a community, have drained the talent pool dry.
-
-We're out of freely available Rockstar Unicorns and so it's time that we started to
-grow our own.
-
-Companies are addicted to hiring the top 5% or 10% of developers and ignoring
-the rest. There is a lot of great talent in the remaining group of developers,
-just waiting to be mentored. If they got that mentorship, we would be able to
-bolster our community's best and brightest. What if the next person your
-company mentored went on to become your next CTO? What if they went on to be
-that "10x engineer" who can help out anyone on the team with anything? I
-really believe companies are missing out on great talent by completely
-ignoring it when it is non-obvious.
-
-Too many companies are focussing on the short-term goals of shipping code,
-rather than the long-term growth of their teams.
-
-Companies hiring the best-of-the-best -- the people with proven great track
-records -- and getting them to build what is essentially CRUD
-applications which do, at best, a fancy version of string concatenation.
-
-If we speak in terms of hiring piano players: you're hiring the Chopins,
-Bachs, Liszts, and getting them to play Mary Had A Little Lamb.
-
-You do not need to hire senior developers. You need to hire developers of any
-skill level, mentor them and grow them into the next great bunch of
-developers. Give these people a chance and train them on real world
-applications that real people are using. These could be the next great people
-that your company needs and you are not giving them the opportunity.
-
-Contributing back
-
-You might be thinking: what do we (as a company) get out of this? I think
-that's backwards. The thinking should be "we have earned so much from the
-community, and now it's time to give back". If you invest in the long term
-health of the community, it will pay dividends. In the long run, you will have
-an active talent pool of developers who will be able to maintain your
-application. In the short term, you'll be bolstering your team's productivity
-with fresh talent.
-
-You may think that you need to hire these best-of-the-best badasses because your
-application is a large unmaintable behemoth monolith and only the badasses
-can understand it. That you need seniors to navigate the spaghetti that is
-your legacy code. That may indeed be the case. But in every monolith, there is
-a tiny bit of functionality that a non-senior developer can work on improving
-along with their skills, when that non-senior is paired with a senior developer.
-
-It's OK to hire non-senior developers to work on real live production code.
-We've done it at Marketplacer and we're still in business. Your company will
-not go down in flames because you hire a junior.
-
-Yes, it's risky. Initially the cost of the employee is greater than what they
-provide for the company. But with the right fostering, they can grow into the
-best asset your company has ever had.
-
-Julia Claven has a great graph for this:
-
-
-
-When the junior is initially hired, their dollar value to the company is less
-than the output they produce. With good mentoring, they can get the other end
-of the graph where their value to the company outweighs their salary.
-
-There is an initial productivity hit -- that's true -- but that plateaus out
-within 6 months if you do it right. At the end of it, rather than having one
-developer, you have two developers. Even if the junior is half as productive
-as the senior, then it's still a 1.5x growth in the productivity of your team.
-
-At Marketplacer we've hired juniors within the last year that I would consider
-to be very productive members of the team, and they're great people to work
-with to boot. We would've missed out on these people if we didn't invest the
-time in hiring and mentoring them and instead focussed on only hiring seniors
-who had existing Rails app development experience.
-
-You might be thinking "but what if they leave"? That's a risk you take with
-any hire of any skill level. If people are leaving your company, you should be
-reflecting on why they're leaving in the first place. Was it really them, or
-was it your company? Does your company have a culture that someone would want
-to leave? Is your company focussed on building a culture that people want to
-stay in, or are they only interested in shipping code?
-
-Finding Juniors
-
-Where can you find those juniors to start with? Well, let's start with Code
-Academies. Not any particular one -- although Turing
-is my favourite. Code Academies solve part of this lack of mentoring problem.
-
-Code academies get new programmers to pay thousands of dollars to learn the
-tricks of the trade. Sometimes, these new programmers even get a "guarantee"
-from the code academy that they'll get a job at the end of the course. The
-code academies teach these newbies a range of programming skills. At the end
-of this, the newbie programmers have enough skills to know the basics of
-things like HTML, CSS, JavaScript and Ruby and can usually find their way
-around a Rails app easily enough. These people are very "green" and then
-they're thrust out into the community to work at companies.
-
-Unfortunately, due to our senior hiring addiction, we're not hiring these
-fresh faces. The code academies produce great talent, and we're not picking it
-up. These people are left to struggle for months at a time in developing their
-skills before they can even get a look in at a company. I've spoken to many
-juniors in that position.
-
-Not all of these graduates have the time to spend doing that skill
-development, as they often have full time jobs or other responsibilities to
-take care of. Thankfully, they get a lot of assistance from their code
-academies after they've graduated. Well, at least the good code academies do
-that.
-
-I would love to see companies breaking their addiction to seniors and more
-actively hiring from these code academies. More companies need to make
-mentorship / apprenticeship a part of what they do. The students that graduate
-from code academies are eager to learn and are, in my experience, very highly
-motivated.
-
-There are definitely juniors who have that same kind of eagerness-to-learn and
-motivation who have never been to a code academy. These people have learned by
-themselves and by being mentored by people in the community. I can think of
-at least 5, perhaps even 10, of these people who would make great hires in a
-company's mentorship / apprenticeship program.
-
-If I were in charge of hiring at Marketplacer, I would hire a motivated
-junior, pay them a wage well enough to live off and mentor them.
-
-Asim Aslam (@chuhnk) had a good tweet about this too:
-
-
-
-There's a great book I encourage you all to read: it's called The Talent
-Code. As the subtitle says "Greatness isn't born. It's grown." The book
-covers how skills of all varieties are grown in sports, music and plenty of
-other areas. All the industries that are covered in the book have active
-mentorship and apprenticeship programs. Yet, this is not cared about in the
-programming community for reasons mentioned earlier: we're still quite a young
-community.
-
-I'll let you in on the secret that's in that book: for anyone to get better at
-anything, they need to practice the hell out of it. How do we expect to have
-seniors to hire if we're not hiring juniors and letting them improve their
-skills by practicing on real world applications?
-
-So many people are talking about mentoring and hiring juniors. Let's start
-doing it.
-
-Mentorship
-
-Now that I've (hopefully) convinced you to hire a junior developer, you might
-be wondering what you do once you have one.
-
-I help run the Melbourne Ruby Hack Night and it's a judgement-free environment
-where anyone and everyone can bring along a Ruby project and work on it. Some
-people are even there for the first time learning about Ruby itself, which is
-great to see. These Hack Nights work because these new developers feel safe
-and welcome and that no question is too "dumb" to ask.
-
-You can start mentoring at your company by fostering that Hack Night-esque
-environment. It should be OK to put up your hand and ask a question about
-anything. If the questioner is getting eyerolls, sighs, or other passive
-aggressive signals from someone else, then that's not the kind of environment
-where a junior is going to learn.
-
-A great way to build that kind of fostering environment is to encourage pair
-programming. Pairing with juniors on small tasks initially is a great way to
-build up their confidence. When I've been mentoring juniors, the number one
-thing that I find that they're lacking isn't the skill, but the confidence.
-They know the answer, but they aren't sure if it's the right answer. They
-question if they're using the right syntax or even if they should be writing
-the code that particular way. When a senior pairs with a junior, they can
-encourage them to try out things and learn from the things that they try. If
-the junior gets it wrong, the senior can ensure them that it's OK to get
-things wrong and to guide them back on track. Pairing is the quickest way to
-upskill a junior and I can highly, highly recommend it.
-
-I paired daily with some developers when I worked at GetUp and in a few
-months time they were confident Rails developers who could find their way
-easily around that Rails application. I've done the same at other companies too
-and each time I've seen great professional growth in the juniors that I've
-mentored. One of the best feelings in the world is when a junior says
-"Ahhh, I understand!".
-
-Pairing also helps reinforce your own knowledge. If you can't explain
-something to someone clearly, then you do not understand it well enough
-yourself. Pairing is helpful to the junior because they get knowledge out of
-it, but it's also helpful to the senior: they learn how to share what's in
-their brain with other people in a clearer fashion.
-
-What should you pair with your junior on? Well, Lydia Guarino has some good
-tweets about that.
-
-
-
-
-
-I agree with both of these. Juniors thrive best when they're given quick wins.
-You want that nice tight feedback loop to keep their confidence growing. Every
-time they "win" at code, their confidence gets that little bit more boosted.
-
-Once they've built up a bit of confidence, you can let them go solo on a task.
-There isn't a set timeframe for when this happens; it's all about how
-confident the junior is with their own abilities.
-
-Let them loose on something small and make it clear that they can ask any
-questions about what they're doing and that there is no wrong way of doing it.
-Once they're done, get them to submit their work in a pull request -- you
-might have to teach them what one is first -- and then sit together and review
-it.
-
-Sitting together is important here because "why are you doing this?" written
-in text has no emotion, compared to it spoken with body language. Juniors may
-interpret a "why are you doing this?" comment as aggressive like "UGH! Why are
-you doing this?".
-
-Focussing on in-person communication helps establish a rapport between the
-developers much better than text-based communication ever will.
-
-If a junior has made a mistake in the pull request then you can discuss it
-with them and correct the mistake. This way, that mistake will never make it
-to a live production environment.
-
-Code review also allows the senior to assess how well the junior
-has been doing on the tasks they've been given. If they're doing well on a
-2-day task, then it's probably going to be OK to give them a 4-day task too.
-If not, then some more mentoring may be required.
-
-Ultimately, your mentorship should be about making the junior feel welcome and
-safe within your team. In fact, this should be what's happening with
-everyone in your team. Google ran a project that they called "Project
-Aristotle", wherein they attempted to find how to build effective teams. They interviewed hundreds of their own employees and they came up with 5 things:
-
-
-
-The #1 item on this list is "Psychological safety": "Team members feel safe to take risks and be vulnerable in front of each other."
-
-Google is not special. They're made up of people just like your company is
-made up of people. You should keep this in mind when mentoring your juniors,
-and working with other people in your team.
-
-
+Thanks everyone for buying this book, reading it and providing feedback along the way.
@@ -349,6 +54,8 @@