00:00:05.920
Lovely! Okay, hi everyone! It's really nice to see you all. My name is Harriet Oughton and I'm a full-time software developer at Zivio. I work Monday to Friday because I love to code. On weekends and evenings, I also serve as a part-time batch manager for Le Wagon's web development boot camp, because I love to self-punish.
00:00:12.360
Let me give you a little context before we get into it. Before I retrained at a coding boot camp, I spent ten years as a classroom teacher and musician, so I think it's safe to say I like an audience. I wanted to pitch a talk for a tech conference, and the amazing Emily S. from the Women and Non-Binary Ruby Group offered to help me come up with a topic.
00:00:28.960
Part of her advice was to consider what is the one thing you have knowledge, experience, and access to that others don’t? My answer was a huge network of early-career developers through teaching and managing the part-time course at Le Wagon. I estimate that I've been involved in some way with around 250 students' coding journeys as early-career developers. In fact, I spotted at least one of them in the audience today, so maybe if you'd like to give them an off-the-cuff coding test during the break, you’ll see my efficacy as a teacher.
00:01:05.640
Many of these students I've taught have gone on to become teachers themselves in their first few years in professional roles, so I'm able to chat with them frequently and triangulate their most common experiences. I'm here today to pass on those experiences to you in the hope of achieving two goals. If you're an early-career developer, it can be easy to feel inadequate, particularly in a small team, as Ruby teams often seem to be. Maybe you are the least experienced member, as I was for the first year of my career. However, know that you are not alone.
00:01:39.600
You'll be meeting some of these challenges for the very first time, just like everyone else, and maybe you'll take away some tips and tricks for tackling them. If you're a more experienced developer, we know that the learning curve is steep, and it can be easy to forget our anxious feelings around writing our first tests, pushing our first PRs, and choosing an edgy GitHub username. If you already have an early-career developer at your company, hopefully, this will serve as a reminder of the things that they are new to, along with some tips to help them get comfortable quickly.
00:02:01.840
If you do not have an early-career developer at your company, you're doing it wrong. Please see me after this session for a stern talking-to. While we're at it, I have a list of some of the most wonderful and eager early-career developers entering the industry who really deserve a first chance. I'm joking about the stern talking-to, but I would be happy to give recommendations of UK-based boot camp graduates who are looking for positions.
00:02:44.640
Hopefully, this talk will reassure you that it's very easy to settle them in and have them making high-quality contributions quickly. By the way, I know a bunch of boot camp grads, but what follows could be the experiences of anyone who has spent a good chunk of time—typically around a year—learning the fundamentals of software development and has built themselves a nice-looking app or two. We meet them now as they are in the first few months of their first professional role.
00:03:10.360
With that in mind, let's receive some postcards from early-career developers. Setting up my environment was both draining and confidence-crushing, much like going for a jog with Usain Bolt. Unfortunately, the first day setup is the baptism of fire that no one asked for. You’re given a lot of complicated and obscure code that you'll mostly run once and not have to grapple with again until you start somewhere new.
00:03:28.200
This is probably akin to a junior doctor on their first day being met with a rare accident and having to stitch all four of a patient's limbs back on. However, no one else on duty can remember the limbs class, so the junior has to follow a handbook written long ago, filled with terminology they don't understand, and have their patient up and about by tea time.
00:04:00.640
Early-career developers, don’t panic if you don’t understand every command you run as part of the setup at the start; just follow the instructions one step at a time. Be thankful that no one's limbs depend on it. Although you may not use these commands regularly going forward, you will develop more familiarity with how everything you set up fits together as you start working on the software. You can always write things down during this time and research them later on when you feel more confident.
00:04:42.880
Concentrate on getting everything working smoothly and in a way that you are happy with, even if you need to ask for lots of help so you can start getting some coding wins. You may feel a bit out of your depth at first, but you aren’t. Treat setup as an unusual time. If you do find a fix for a problem or a good article explaining a part of the setup, be sure to offer to document it for the next new starter, which will help you feel like you are positively contributing right from the outset.
00:05:35.920
To more experienced developers, you can really help by ensuring that setup instructions are clear and simple to follow, and that they don't assume any knowledge at all. Think about pairing the new starter with another developer who has done the setup recently—ideally another early-career developer. Not only will this build confidence in the other early-career developer, but they will likely have fresher knowledge of any problems encountered and a similar hardware setup.
00:06:06.960
It's also worth starting a list of handy code editor extensions, like VS Code, and keyboard shortcuts that you use daily. Leave them somewhere easy for the new starter to find, so they can come back to it when they’re not feeling as frantic and confused.
00:06:32.200
The workflow was totally new to me. I thought a 'git fix-up' was a terrible blind date. Early-career developers will be entirely new to your company's professional coding workflow, which means they will be learning Git commands beyond adding and committing, for example, git rebase, git fix-up, or git merge, and learning how to create professional pull requests (PRs) and respond to code reviews by more experienced developers.
00:07:09.360
It can be helpful for early-career developers to write yourself a cheat sheet or a flowchart and have it available on their desk, so you can see your workflow easily as you get used to it. Tools like Miro can be useful for visualizing this. Find out early on, or even before you start, if your company has a style guide for commits, commit messages, branch naming, and PRs, as many do.
00:07:54.320
This will spare you the embarrassment of committing with the message 'test first commit' or 'does this work?' to the repository. Once you know which Git commands you'll be using frequently, you can add these to your alias file if you're using Z shell (zsh). You can open the zsh config file and add aliases there.
00:08:14.160
If you're using VS Code, enable the Git extension in the tabs to the left for a more visual way of interacting with everything Git. Learn how to review PRs and offer to take simpler ones or at least make comments on existing ones to start flexing your reviewing muscles.
00:08:46.720
However, if you are going to leave comments, perhaps check with the rest of your team first that this is okay with them to avoid unwanted opinions, which could lead to unpopularity and no invite to the Christmas party. More experienced developers, it’s helpful if you can create a simplified commit or PR style guide and make sure it's easy to find for new starters.
00:09:13.200
Also, this goes without saying, but try to be encouraging and gentle on PRs, especially when they’re starting out. We're told that the ideal positive to negative comment ratio should be five positive comments to one negative comment, including positive comments on lines you're impressed with or something you haven't seen before. This goes much further to creating a confident developer than comments like, 'What were you thinking?' or 'This syntax makes me want to throw up.'
00:09:46.320
Needing to run 'destroy all' in the production console is scarier than the Saw franchise. Working for the first time with real data when you start your job can be intimidating, and this is normal. Whatever you mess up—and you will mess something up in the production console at some point in your career—you can guarantee that everyone at your company has stories that are ten times worse.
00:10:29.600
Remember, too, that any work you do in your local database will not affect the actual production data. It's a good idea to clone, i.e., copy the data regularly, so you can try commands in your local database or console first, just in case it has side effects you didn't anticipate.
00:10:54.040
If anything goes very wrong with your local database, you can always drop it and start again, but remember not to do this in production as it’s another sure way to lose that Christmas party invite. You can also experiment with tools like MySQL Workbench that allow you to write and run SQL queries on the database away from the code itself.
00:11:41.600
To experienced developers, support your early-career developer with how scary it can be when they start manipulating new data. Make it clear that it’s okay for them to run a line of code past you before they execute it in the production console for a sense check or a second pair of eyes. You could even make this standard procedure.
00:12:19.600
More importantly, be human in front of them. Share stories about times you’ve messed up so they can learn from your mistakes, which will stop them from viewing you as all-powerful and infallible—like Thor of the coding world—unless that’s the working dynamic you like.
00:12:46.360
Our new releases don't seem to be as hotly anticipated as Taylor Swift’s. Chances are that unless you really went all out with your to-do list app that you learned from a YouTube coding tutorial, you won't be used to the release cycle of software yet. And that’s totally okay!
00:13:30.800
When we talk about your development environment, that means the code you write on your own laptop using a local copy of the database, which may have been cloned or copied or may contain dummy data. No changes you make to this code will affect anything that users see in your real app. Once your code has been reviewed and merged into the main branch on GitHub, most companies will first promote it to a staging app for thorough testing before it is finally promoted again to the real or production app that users will see.
00:14:10.640
Before code is merged, it also goes through the continuous integration process, which includes a series of tests that must pass before your changes can be added to the main branch. More experienced developers can help by writing an overview of any services used for hosting or deployments, along with the workflow associated with them.
00:14:44.800
This provides an early-career developer with a broad level of understanding, even if they’re not hands-on with the deployment process. You could even offer them the opportunity to observe you during a deployment so they gain tangible experience of the process and understand how their pieces fit into the puzzle.
00:15:20.280
A horse walks into a bar, and the barman asks, 'Why the long code base?' I'll let that one sit for a minute. When early-career developers work on a complex piece of software for the first time, they often find it challenging to get to grips with a large code base. They can become phased by the sheer number of files and will probably encounter new concepts such as modules and inheritance.
00:15:48.560
They also often won’t know how to tackle problems or debug their own code; advising them to just Google it won’t help either. Early-career developers, take your time understanding what each line of code does, and don’t feel pressured to push lots of code quickly. Sacrificing your understanding of what the code is doing will only lead to trouble later.
00:16:26.280
Before you all scream, 'AI is going to steal our jobs!', know that this is an opportunity to use ChatGPT or similar tools effectively. Paste complex lines of code in and ask it to explain what they do. If you can’t find where a method is defined in the file, it might be inherited from another file, so check the top of the class. Failing that, it might come from a gem; Google it to find out.
00:17:03.720
Take time reading the documentation of any gems you know are used or you've heard mentioned so you can understand their function. If you run into a bug, don't worry, we all do. Take guidance from seniors on how long they want you to stay stuck thinking—i.e., when you run out of ideas and are unsure what to try before asking for help.
00:18:03.520
Try rubber ducking the problem first: explain it to an inanimate object to see if that unblocks your thought process. When you do ask for help, explain what you've already tried and what specifically you think is blocking your progress, as well as the line where the error occurs. This will show others that you're eager to learn and that you're putting in effort.
00:18:37.480
When making changes to complex features, you can sketch flow diagrams in a notebook or use tools like Miro to visually represent how the data is being passed around. At this stage, your primary job is to learn and get familiar with the code. The company expects that from you, so make priority over writing 65 PRs every day.
00:19:01.680
At this stage, your code editor tools are also your friends. I use VS Code, so I can speak authoritatively about that, but similar functions exist in other editors too. The big advantage of VS Code is the Live Share feature, allowing collaboration in real-time and is great for pair programming.
00:19:34.960
In VS Code, you can also use Command + P to search for a file and open it in a new tab, so you don't have to wade through all the files to find what you need. Become best buddies with the search box at the side, which can help trace back where else a method is called from or which file contains the text displayed.
00:20:10.560
To more experienced developers, what will really help is to keep up-to-date documentation around key functionality of the app and how this might interact with the rest of the business. This is really helpful for beginners trying to get up to speed, as they'll need to understand the business decisions behind what they are building.
00:20:41.120
Yes, it's definitely valuable to follow the code and learn to understand a new code base, but the functionality and business decisions can be obscure, even if you understand the code. This will also better enable them to spot bugs, gaps in requirements, and edge cases.
00:21:10.000
Many early-career developers find themselves coding in brand new languages in their first jobs. You're not alone in this; even those coding with the same stack will encounter differences that they find daunting. Again, as an early-career developer, take your time to read existing code thoroughly and Google any unfamiliar components.
00:21:54.440
Don’t be tempted to churn out code quickly that you don’t fully understand. More experienced developers, direct your early-career developer to any training videos and resources you found particularly beneficial when learning the new language or framework. For example, resources from GoRails or Udemy might have excellent material.
00:22:34.760
Many early-career developers find testing a new and unknown frontier. Chances are they would have concentrated more on the basics of making working, nice-looking software, rather than defending it against every obscure edge case.
00:22:54.560
When starting out with testing, it’s a good idea to search through the software for a similar feature to the one you just built and copy that test file, adjusting some details to suit your feature. If you find it difficult to write accurate tests, concentrate on getting your feature working first and worry about tests afterward.
00:23:43.560
If you’d like a good resource to get started, Jason Swett is an excellent source of knowledge on all things testing through his social media, podcast appearances, and his excellent book, The Complete Guide to Rails Testing. This is a second shout-out for Jason Swett today.
00:24:27.280
More experienced developers, explaining exactly what needs to be tested as you delegate tasks to early-career developers can be tremendously helpful, along with providing similar test examples they can look at and apply in their work.
00:25:03.760
In summary, more experienced developers, if you don’t already have one, please hire an early-career developer. Chosen well, they will be so grateful for the opportunity. They will work hard and contribute significantly in a short timeframe. Even small contributions are incredibly useful and will help free up your more experienced developers for tougher projects.
00:25:59.520
It can be tough to hire mid-levels and up, so why not grow your own in-house? Just add water, encouragement, and a couple of easy-to-action tips, and you will have a great team member before you know it.
00:26:38.880
Early-career developers, the best thing you can do for your confidence is to remember that you are not alone. Getting involved in the Ruby community outside of your company will help remind you that many others are in the same boat, struggling with similar challenges.
00:27:01.760
International organizations like WMBB or local coding chapters in your city are good places to start, as are attending conferences like this one and listening to podcasts aimed at beginners, like Ruby for All.
00:27:27.680
Alternatively, you could mentor someone learning Ruby for the first time, or connect with your own mentor through resources like FirstRubyFriend.org.
00:27:54.800
I hope this has been really useful for you all. Feel free to connect with me on social media or come and chat with me after the session if I can help in any way. I'm grateful to you all for listening attentively to my talk. I can say wholeheartedly that you've been a much quieter and mostly better-smelling audience than the room full of teenagers from my previous career. Thank you so much!