This blog post is musings, which may flesh out into something concrete. YMMV

I’ve been thinking recently about all the support networks out there for junior developers. There are so many excellent programs out there for first-time developers, those who have come into programming from other industries, for juniors, for those who are re-skilling later in their life, and more. There are bootcamps, meetups, conferences, workshops, short-courses, mailing lists and the list goes on

There are networks out there for the senior developer. The thought-leaders, the managers, the architects. There are C-level conferences, Slacks, coffee meetups and the like.

But in all of these, there’s nothing for the developer who has changed stacks.

Not a polyglot: someone who actively develops in more than one language in the same space; e.g. Haskell and Python. Nor a Full-Stack developer, someone who develops languages and constructs at multiple layers of the stack.

Not a beginner/junior dev: they have years of experience in the industry in another programming language or completely different stack – say going from MSSQL/Windows to PostgreSQL/Linux – but they just don’t have experience in the new stack.

I’m talking about – and this term is still a bit iffy as I can’t think of a better term – the Lateral Developer. Someone who has been doing software development for years and knows how to code, but doesn’t know your code.

They don’t need the resources for Junior developers. If they have worked with any database before, there’s a high chance that they know that tables and foreign keys and clusters are a thing, but they just won’t have the practical experience in your database. What they need is to know the differences between their database stack and yours. For example: while MSSQL SQL and PSQL SQL might look similar, there are little differences that would be really good to know when starting out. Like the mandatory semicolon to kick off intepretation in the psql cli. Or that database dumps generated by pg_dump don’t use INSERT statements, they use COPY. They probably know their way around a terminal and have their own preferred version and setup, so your pandering about how zsh is a REAL terminal isn’t helpful. For someone who hasn’t used a terminal before, there’s space to pick up a terminal which happens to be yours. But if it doesn’t block them from doing their job, let them use what they know.

They don’t need the resources for team leaders or senior developers. They probably already have these mentoring skills from their previous languages, but lack the specific technical know-how for the new stack in order to teach others.

What the need is a structure where they can openly ask the questions about the bits they are missing without being assumed that they are stacking from nothing. They have years of foundation, but just not your foundation. While, granted, being told about a more efficient looping structure would be helpful, what is unhelpful is trying to teach them what a for loop is.

Funnily enough, I’ve given a number of talks about these edgecases. The talk has evolved over the years, but is historically available on YouTube as “JavaScript is Awe-ful”. Depending on which vintage you find, the talk has progressed from “Here are some JS edge cases” to the most recent version (at time of writing) from RubyConf AU 2018 which is literally 20 minutes of “Here are a bunch of gotchas from a bunch of languages and why they exist. They are there because languages are developed with design considerations in mind”. For some attendees this was seen as a “Wow languages are cool!” and others saw it as “Oh, that’s why X language does things differently”. The first time you encounter the fact that == works differently in different languages is the first time you realise that you can’t assume programming paradigms from your language maps to other languages. But knowing what differences exist is vital to be able to quickly skill up in that new stack.

I’m still evolving this idea in my head, trying to work out a good term for this segment of developer, and starting to think about how I could help them gear up in their new stack. But for now, it’s just something for us all to think about.

Just because someone doesn’t know your stack doesn’t mean they don’t know anything.

Directions I may take this dicussion in the future

  • Training vs Education
  • Thoughts on Apprentice -> Journeyman -> Master progression, applied to tech