Dated: Jul 26, 2023
I’m attempting to obtain the diploma in every mainline Pokémon game, a long-running project that I call the Pokémon Diploma of Diplomas. To learn more about this project, check out the overview I wrote detailing the rules and my progress.
In Generation I, receiving the Diploma requires owning 150 species of Pokémon. For the purpose of the Pokémon Diploma of Diplomas project, Generation I includes only Pokémon Red, Blue and Yellow, and playing all three games in order to obtain the Diploma in all three requires a little bit of planning.
In this post, I will lay out my plan for getting the Diploma in the three Generation I games.
Version exclusives
Red and Blue are “paired versions”, meaning that each version contains exclusive Pokémon, but all the Pokémon required to complete the Pokédex are available in the two games.
Yellow is the “upper version” or the “third version” and contains no exclusive Pokémon. However, it will still be very useful for assembling a Pokédex, particularly when it comes to evolutions and mutual exclusives (detailed in the next section).
There are 3 Pokémon obtainable only in Red:
There are 8 Pokémon obtainable in Red and Yellow but not Blue:
- Oddish
- Gloom
- Vileplume
- Mankey
- Primeape
- Growlithe
- Arcanine
- Scyther
There are 3 Pokémon obtainable only in Blue:
There are 8 Pokémon obtainable in Blue and Yellow but not Red:
- Sandshrew
- Sandslash
- Vulpix
- Ninetales
- Bellsprout
- Weepinbell
- Victreebel
- Pinsir
There are 7 Pokémon obtainable in Red and Blue but not Yellow:
- Weedle
- Kakuna
- Beedrill
- Raichu (lol)
- Koffing
- Weezing
- Jynx
Mutual exclusives
Mutually-exclusive Pokémon refer to sets of Pokémon that are each obtainable in a single version of the Pokémon games, but where obtaining one of the Pokémon in the set precludes obtaining the others.
That sounds more complicated than it really is. The easiest way to understand this is to think about the Starter Pokémon: you can only choose one Starter Pokémon. Once you’ve chosen your starter, the other two Starter Pokémon become unobtainable without trading. This means that I will have to plan which mutually exclusive Pokémon to pick up at various stages of each game, in order to ensure that I have full coverage of the Generation I Pokédex.
In Red and Blue, there are four types of mutually exclusive Pokémon:
- Starter Pokémon
- Eeveelutions
- Fossil Pokémon
- Fighting Dojo Pokémon
I’ll go over each of these categories separately.
Starter Pokémon
In Red, I chose to start with Charmander. Red was the version I played as a kid and Charmander was the Pokémon I chose, so it’s a no-brainer. That means that I will need some way to get the Squirtle and Bulbasaur families into the Red game.
In Blue, I plan to start with Squirtle. Because Squirtle is blue. (And also because Blastoise is the version mascot for Pokémon Blue, which I’m sure has nothing to do with the fact that Blastoise is blue.) That means I will need to get the Charmander and Bulbasaur families into the Blue game.
While I could transfer Squirtle into my Red game and Charmander into my Blue game, there’s a bit of logistics involved in making sure the trades happen at each evolutionary stage. I plan to focus on one game at a time, and I also plan to keep Charizard and Blastoise in my main party for these two games, so it’s a bit distracting if I have to switch games just before the starter Pokémon are about to evolve. It also doesn’t solve the problem of getting the Bulbasaur family.
Fortunately, there’s a solution in the form of Pokémon Yellow. In Yellow, Charmander, Bulbasaur and Squirtle are all available as Gift Pokémon. I do plan to keep all three Pokémon in my main party, though, so the Pokémon still have to be traded back and forth. When I get each of the following Pokémon in Pokémon Yellow, I’ll trade them into Pokémon Red and/or Blue, and back:
- Bulbasaur (to Red / Blue)
- Ivysaur (to Red / Blue)
- Venusaur (to Red / Blue)
- Charmander (to Blue)
- Charmeleon (to Blue)
- Charizard (to Blue)
- Squirtle (to Red)
- Wartortle (to Red)
- Blastoise (to Red)
Eeveelutions
In each of the Generation I games, there is only one Eevee obtainable. However, there are three Eeveelutions in Generation I.
I typically evolve Eevee into Jolteon and use Jolteon in my main party. I will continue to do that for Red. In Blue, I plan to evolve Eevee into Flareon, but probably will not use it in my party (if I keep a Fire Pokémon in my party, it will be Vulpix/Ninetales). That leaves Vaporeon for Pokémon Yellow.
Fossil Pokémon
There are two mutually-exclusive Fossil Pokémon families: Omanyte/Omastar and Kabuto/Kabutops, obtained through reviving the Helix Fossil and the Dome Fossil respectively.
In Red, I pick up the Helix Fossil (praise Helix), and in Blue, I will pick up the Dome Fossil.
Fighting Dojo Pokémon
In Saffron City, there is a Fighting Dojo where the Karate Master will give the player character either a Hitmonlee or Hitmonchan.
I habitually pick up the Hitmonchan in Pokémon Red, so I’ll be picking up Hitmonlee in Pokémon Blue.
Trade evolutions
There are four other Pokémon in Generation I that do not fall into the above categories, but that nonetheless require trading to obtain:
- Alakazam
- Machamp
- Golem
- Gengar
These Pokémon only evolve from their prior forms when traded. Machamp is available in Pokémon Yellow when a NPC trades you their Machoke, but the others are simply not available in a single game without trading to another cartridge.
When to trade?
Initially I thought I should aim for all obtainable Pokémon in each game before trading, but this is not really possible because some lower evolutions are permanently missable (e.g. mutually exclusive Pokémon need to be traded at each evolutionary stage).
At the same time, I want to impose some basic guidelines for when to trade, so that I’m not cheesing Pokémon Blue or Yellow by trading stronger Pokémon in too early. Additionally, at some point or another, I will need to have more than one game running in parallel, which could divide my attention and make the logistics of trading quite messy.
Here’s the plan: I’ll play Pokémon Red and Blue through to the credits, then do the Red/Blue trades. That should allow me to fill out my Pokédex in both games except for the Bulbasaur family and Vaporeon. When I play Pokémon Yellow, I’ll trade Bulbasaur/Ivysaur just before and just after it evolves, then finish playing Yellow to the credits, and complete the remaining trades.
This way, I’ll retain the single-player experience up to the Pokémon League, but with a post-game where I can have some fun with Pokémon I never got to use as a kid, such as Alakazam and Gengar.
Round-up
That’s all the planning I’ve done for Generation I. If you’re interested in following along with the Pokémon Diploma of Diplomas journey, you can check the YouTube channel or follow my Twitch stream to get notified when I’m trying to catch’em all.
Dated: Jun 23, 2023
This is a living document about a long-running project. Expect details, including the ruleset, to change over time.
A while ago, while reading about what Pokémon players needed to do before the closure of the Nintendo 3DS eshop, the germ of an idea took root in my head and refused to die:
I should diploma every Pokémon game.
The diploma, for those of you who aren’t familiar with Pokémon, is an in-game achievement in the mainline Pokémon games awarded to players who literally catch’em all.
As a kid, I completed many of the Pokémon games, but I never completed a Pokédex. Initially, I jokingly referred to this project as “Childhood Wish Fulfilment”, but as much as my inner child wants to keep that name, “Diploma of Diplomas” is a much better name for this project.
Streams and Videos
I’m streaming this project on Twitch and posting the videos to YouTube.
I don’t have a regular schedule, but I’ll try and put in at least an hour a week. This is going to be a very long-running project.
Progress
As of 3 Sept 2023, I am playing Pokémon Red (YouTube playlist).
I am on game 1 out of 41 (see Game List below).
In this game, I have caught 57 out of 150 Pokémon required for the diploma, and earned 6 out of 8 gym badges.
Self-Imposed Rules
There are some ground rules I’ve set for myself on this project:
- No PC-based emulation or flashcarts for diploma save files: Leaving legality aside, this project is about grown-up me fulfilling childhood fantasies of completing a Pokédex on Nintendo hardware.
Because I want to stream this project, a little futzing around this rule is necessary: I have a Gameboy Advance modded with mini HDMI out, a New 3DS XL modded with a hardware capture card, and have an Analogue Pocket on the way. That’s why I have the weaselly modifier that no “PC-based” emulation is permitted.
I acquired the entire catalogue of GB, GBC, GBA, DS and 3DS core Pokémon game cartridges; to the best of my knowledge, these game cartridges are genuine, and yes, I am a sucker for paying those prices. Almost anything can be justified when you call it “childhood wish fulfilment”.
Regarding flashcarts: there is one situation in which I expect to need a flashcart to complete the Pokédex. FireRed and LeafGreen have three Roaming Pokémon (Raikou, Entei and Suicune) that are all required for the Pokédex, but only one Roaming Pokémon can appear in each game! To work around this, I plan to start a game on either FireRed or LeafGreen, play until I catch the Roaming Pokémon for that game, then dump the save file and load it onto a flashcart. I will then restart the game on the original cartridge and trade the Roaming Pokémon into it.
- Start from Generation I, and do not move on to the next generation until I have obtained diplomas in each game in the current generation: This rule is self-explanatory. An additional note: I consider Generation I to consist of Pokémon Red, Blue, and Yellow. Maybe one day I’ll play the Japanese Red and Green, but it won’t be as part of this undertaking.
- Pokémon Legends: Arceus is the exception to the above rule. I will play PLA last: There are two reasons for this. The first is that if I do not have this rule, I will never reach Generation IX. PLA is too long, and its gameplay too different from the rest of the mainline Pokémon games, for me to be able to handle it as part of Generation VIII. The second reason is that it is only right that Arceus be the last Pokémon I catch in this project.
- In games with multiple diplomas, I must obtain all of them: If the game has a Regional Pokédex and a National Pokédex, the diplomas for completing both are required. If the game has multiple Regional Pokédexes and a National Pokédex, all the corresponding diplomas required. If a game has DLC, the DLC Pokédexes are required. The exception to the “every diploma” rule are the Time Travel Awards, which I’ll only do if they’re convenient; I don’t really want to go out of my way to plan for them.
- No transferring of Pokémon to a game where that Pokémon can be caught: If a Pokémon can be caught in that game, it should be caught in that game. Yes, this lengthens each game considerably, but I want to do minimal trading within and across generations.
Important exception 1: Generation II is especially punishing when it comes to Roaming Pokémon. I don’t want to try to catch Raikou and Entei three times each, when doing it once is already a grind, and simple mistakes or bad luck could mean that the Pokémon is gone forever. For Generation II only, I will allow Raikou, Entei, Suicune and Ho-Oh to be traded back and forth. (Although Ho-Oh is not a Roaming Pokémon, Pokémon Crystal requires you to be the original trainer of Raikou, Entei and Suicune for that save game in order to catch Ho-Oh, so permitting trades of the three Roaming Pokémon instead of requiring an in-game catch implies Ho-Oh needs to be traded as well.)
Important exception 2: In Generation I, Porygon can only be purchased at the Celadon Game Corner for 9999 coins, and you can only buy 50 coins at a time. That means standing in front of the Game Corner counter and mashing the A button for the duration of ~200 purchases watching the coin counter go up and my money counter go down. I think this is a profoundly uninteresting endeavour, and I don’t intend to repeat it three times. For Porygon only, I will allow trading between Generation I games even though it is technically obtainable in each game. For Generation II games onward, I haven’t decided if I will apply the same rule, since it’s less of a grind when you can buy 500 coins at a time.
Important exception 3: I haven’t decided how I will obtain Spiritomb in Generation IV, but it’s very likely that I will allow for a similar exception in order to avoid repeating the grind of talking to myself 32 times in the Underground.
- Assembling a Living Pokédex is out of scope: I’ve honestly never really been interested in a living dex. I guess I think of each Pokémon generation as being somewhat self-contained. I’m also not going to organise my Pokémon by dex order, or go out of my way to get all the alternate forms of Pokémon.
- Event Pokémon are not required: Mythical Pokémon are generally not required for diplomas. Where they are required, they’re typically available in-game. The basic idea is that no Event Pokémon are required for diplomas, so no Event Pokémon will be required for this project.
This ruleset is subject to change. The goal is to have fun, and if any of the above rules start to feel like arbitrary constraints on fun, I will revisit them.
Questions and Suggestions
If you have any questions or suggestions about this project, your best bet is to send me a message on Mastodon @grace@mastodon.graceteng.me.
You can also leave me a comment on a YouTube video, if you prefer.
Game List
This list will be updated as new Pokémon games and DLCs get released.
The game I am currently working on is in bold.
- Red (YouTube playlist)
- Blue
- Yellow
- Gold
- Silver
- Crystal
- Ruby
- Sapphire
- Emerald
- FireRed
- LeafGreen
- Diamond
- Pearl
- Platinum
- HeartGold
- SoulSilver
- Black
- White
- Black 2
- White 2
- Pokémon X
- Pokémon Y
- Omega Ruby
- Alpha Sapphire
- Sun
- Moon
- Ultra Sun
- Ultra Moon
- Let’s Go, Pikachu!
- Let’s Go, Eevee!
- Sword
- Shield
- Isle of Armor
- Crown Tundra
- Brilliant Diamond
- Shining Pearl
- Scarlet
- Violet
- Teal Mask (to be released fall 2023)
- Indigo Disk (to be released winter 2023)
- Legends: Arceus
Dated: Mar 6, 2022
Congrats, you’re done with Le Wagon’s Web Development bootcamp. You have 360 hours of classroom time, three Rails applications, and zero professional software development experience. What’s next?
Le Wagon maintains its own career playbook, but depending on where you are and what your goals are, you may find yourself struggling to adapt its advice to your circumstances. I’m just one data point, but what I hope to do here is offer another perspective and perhaps a little direction as someone who was in your shoes not too long ago.
Can I really get a job?
Yes.
I had my own doubts after completing Le Wagon (batch #454), even though code came to me easily during the bootcamp. The doubt came from feeling that everyone who got a job must simply be “better” than me in some way, and that in order to get a developer job, I had to first learn more, practice more, etc. My way of fending off that uncertainty was to be a TA for the next full-time batch in Singapore, #512, and postpone the job search while I consolidated my skills. I don’t regret TA-ing at all, but my decision to TA was definitely rooted in fear of the unknown.
Miguel and Prima, my lead instructors, told me I had the chops to land a junior developer role, and I should go for it. In my mind, I discounted their enthusiasm because I thought, what else would they have said? However, the reality is, if you don’t apply for jobs, you truly have no idea where you stand in the job market. Once you start applying, you’ll get a better sense of what types of jobs are a good fit for bootcamp graduates, and how to best position yourself for them.
Part of the challenge in this job-hunting phase is that you will have to cast a wide net, and apply to jobs that use technologies outside of what you’ve used in Le Wagon. Some companies will be open to hiring juniors who are willing to learn the stack, while others will want you to have a base competency in the tech stack before hiring you. Some of the requirements are learnable within a relatively short time, while other competencies take longer. How can you determine which jobs you are suited for?
In my opinion, you can’t. My approach to job applications was essentially spray-and-pray. I’m ambivalent about this approach: it will be clear to many companies that you have no idea what you are signing up for (which is true), and it can be demoralising for you, the applicant. On the other hand, there will be places willing to hire a junior developer who is trainable. Unfortunately there is no way I know of to distinguish such organisations from the rest, short of applying to all of them and seeing what comes back.
The majority of places I applied to never replied, which is par for the course. I’ve had interviews that went really well, interviews that went nowhere, and one interview that went poorly. All of these interviews help you to learn about the tech job market, regardless of the interview outcome. The interview that didn’t work out sticks in my mind because even though it was a junior role, it required specialised technical knowledge that I simply did not have. The interviewer highlighted the total mismatch between my skillset and the job description, and estimated that it would take me six months of grunt work, reading and writing documentation, before I would be ready to make any code contribution.
On the one hand, I came out of that interview totally deflated. On the other, I learned a little bit more about an area of software development, and what would be expected of a software engineer in that domain, that I might not have otherwise.
With this information, you can start to develop an eye for what jobs you are more likely to be a candidate for, and to create a roadmap for professional development down the line.
How do I make myself competitive for developer positions?
As a career changer, you are not a blank slate.
You are likely to be applying to junior developer jobs, where your main competition is fresh university and polytechnic graduates. You have disadvantages, for sure: many of these graduates will have had a classical computer science education. Their CS knowledge is a known quantity to employers. It’s easy to feel that a nine-week bootcamp, or 24 weeks for part-timers, cannot possibly compare with a four-year degree.
On the other hand, you also have advantages that you can and should lean into:
- You have some general professional skills that come only after years of working experience, such as the ability to independently define and achieve goals, managing competing demands on your time and energy, and the unspoken knowledge of how to conduct yourself in the workplace.
- You have some skills specific to your previous jobs: for me, I highlighted my ability to communicate and to teach, honed from my previous lives as a documentary filmmaker, as a teacher and in customer support.
- Bonus points if you have specialised industry or functional knowledge: understanding how marketers work is great if the company is building a product for marketing professionals. Understanding the logistics industry is great if the company is building technology to solve a supply chain management problem.
- Bonus bonus points if your industry knowledge is in a heavily-regulated field: law, finance, insurance, healthcare, cybersecurity, real estate, etc.
Another thing to understand is that any employer that seriously considers hiring you is not hiring you on the basis of what you learnt in nine or 24 weeks, but on the basis of what you demonstrated.
This is an important distinction: you did not learn enough during the bootcamp to do your job. This is simply a fact: if everything a developer needed to know could be taught in nine weeks, the job market would look drastically different. Instead, what completing the bootcamp demonstrates is that you are trainable as a developer: you learned a tremendous amount in a compressed timeframe, you have the grit to work through things that are technically challenging, and now you have some foundation for learning everything else you need to learn on the job.
Performance expectations for junior developers typically revolve around attitude and ability to learn, not around the depth of your technical skills. This helps to reframe the problem: for jobs where you are a viable applicant, you are not competing against other applicants who know more than you do. You are being considered on the basis of your ability to learn, and that is something you definitely have.
Are my Le Wagon projects really good enough for a portfolio?
The time pressure of Demo Day forces many Le Wagon teams to focus only on features that will be demonstrated during Demo Day, and ignore any features or bugs outside of the demo’s path. It can end up being a very delicate operation: my team found a bug just before Demo Day that forced us to perform the checkout in a very specific order, for example. You may feel that your LW projects are not “ready” to be put into a portfolio that you can show to potential employers. That’s understandable.
In that case, what do you do with your projects? I can only really offer suggestions based on what I did, but hopefully you will find it useful as well.
The goal here is to show a baseline level of technical skill and an abundance of trainability. Instead of focusing on achieving an unrealistic level of polish in your LW projects, identify talking points around your projects and frame the project in terms of learning: what problems did you face while building this project? How did you work through these problems? What did you learn along the way? Put these talking points in your portfolio. This emphasises your ability to learn, and helps to contextualise the projects for potential employers.
Another thing I did is what I call the Redux option : identify 2-3 things that you didn’t get to finish for Demo Day, and complete them. These should be small tasks – fixing a known bug, making the app responsive, making it a simple progressive web app, adding error handling for a feature that only has its happy path completed. Then, if this is not a project you want to work on for the long term, stop here, accept that your early work is not going to be perfect, and move on.
You can see examples of how I wrote up my talking points and presented the Redux versions of my projects here:
What additional skills should I pick up?
I’m hesitant to answer this because it might fuel someone else’s imposter syndrome, but at the same time there are real gaps between what Le Wagon teaches and skills you really do need to know.
The first thing on the list is tests. The Le Wagon experience depends extensively on tests, at least until week 6 (for full-time) / week 15 or so (for part-time). By now you’re intimately familiar with how to interpret a failing rspec test. But can you write one?
If the answer is no, this is the first thing you should learn. There are two reasons for this:
- Everybody should be writing tests!
- Knowing how to write tests makes you more attractive to companies that care about testing, which are also companies that care about building good software, i.e. the companies you want to work for.
The second thing on the list of things to learn is JavaScript. Yes, you learnt five days’ worth of ES6, and then avoided it as much as possible during the projects because you didn’t understand any of it. I know. I understand the reason Le Wagon’s curriculum is built the way it is, and I don’t think I would take out something else to put in more JavaScript.
However, the JS covered in the bootcamp is grossly insufficient, especially if you want to pursue front-end or even generalist full-stack development. At a minimum, I would urge you to watch Codesmith’s videos on Promises, Async and the Event Loop. You must understand how frontend API calls really work, instead of copying the fetch(url).then(response => response.json).then(data => { // do stuff }) magic incantation from Kitt every time you need it. Better still, go through Codesmith’s CSX course, which mimics the style and content of what you learn in Le Wagon for Ruby, except this time in ES6.
From here, there are not as many hard-and-fast rules. I think many Wagoners would say to learn React , and I definitely think React is a good choice – but I actually don’t know if I consider it strictly necessary unless you definitely want to do frontend work. In my opinion, React is useful to learn because it gives you a mental model that is very different from Rails, and that you can then use as the starting point for learning other things. The course I typically recommend is Brian Holt’s Complete Intro to React v6 (if v7 is out by the time you read this, search for that instead).
Two more things I would add to this list are a high-level understanding of infrastructure and networking. You don’t need to understand the details at this stage, but you should understand how exactly a web application lives on a computer somewhere and how users somehow get that application delivered to their web browser.
Infrastructure and networking aren’t necessarily something that will come up at the job interview stage for a junior developer, but it makes your life as a developer vastly easier if you have a mental model and a vocabulary for talking about infrastructure and networking to your colleagues once you’re on the job.
How do I keep learning when I can’t raise any more tickets?
This is not an original visualisation:
Three concentric circles. The innermost circle is labelled “Comfort”, the middle circle is labelled “Learning”, and the outermost circle is labelled “Panic”.
You’ve developed some familiarity with Rails, and a mental model of what software development looks like. That’s your comfort zone.
Outside of your comfort zone, there’s a zone of proximal development, or a learning zone. This is where you can learn something new if you can relate it to something you already know: you can read a tutorial and learn by analogy based on what you already know, or you can watch a video and follow along reasonably well. You want to stay in this zone as much as you can.
The great beyond is the panic zone : when you’re confronted with something so new, you don’t have a frame of reference at all. You want to stay out of this zone: spending too much time here makes you feel dumb and demoralised.
Over time, things that were formerly in your learning zone become your comfort zone, and the comfort zone circle expands. Things that were formerly in your panic zone start to come into your learning zone.
If you find yourself panicking when faced with something you don’t understand, take a step back, and see if there’s a way you can connect it with something you know, and build up to it that way. If there isn’t, there’s no shame in accepting that you’re not ready for it yet, and finding something else that does fall within your learning zone. Eventually, you’ll learn something that allows you to bridge that gap.
What should I consider when deciding on my first software development job?
My answer is going to be heavily biased by my experiences at Thoughtworks, which has been an excellent place for me to start my software development career. You should definitely talk to other alumni and other software developers, who will probably give you a variety of responses that you can consider in your decision-making.
In my opinion, the first thing you should look for is availability of mentorship : specifically, what support do junior developers get to develop their technical skills?
This can take many forms: a company may highlight its L&D budget, or give you access to many learning resources on Udemy, O’Reilly, or whatever its learning platform of choice is. The thing I would ask about, though, is what kind of technical feedback you can expect : do senior developers actively mentor juniors and give feedback on their code? If you’re unsure about something, can you get an extra set of eyes on it to verify you’re on the right track, or will you be left to your own devices? Feedback is critical to learning, and without feedback, it will be challenging to gain confidence in your skills as a developer.
The next thing I would look for is the quality of software engineering practices in the team or in the organisation:
- Does the team write tests? A team that is committed to maintaining high test coverage of their codebase is generally a team that cares about software quality, and is likely to be a team you can learn a lot from.
- How integrated is QA into the development process? Ideally, QA should be fully involved in the development process from start to finish: from gathering requirements, to defining a testing strategy, to performing QA after each user story is “dev done”. The larger the chunk of work that QA is expected to work on at a time (e.g. if QA is performed on an entire sprint’s worth of work at a time), the slower the feedback loop will be for you as a developer, and the harder it will be for you to learn from your mistakes.
- How is code review conducted? Different organisations have different opinions about this, but the critical component is, once again, fast feedback: the sooner you get feedback on how to improve your code, the faster you learn and improve as a developer.
- How frequently does/can the team deploy code? In my opinion, this is less of a direct factor that affects your job experience, and more of a proxy indicator. A team that is capable of deploying frequently is a team that maintains a high level of software quality. Just like with tests, that suggests a team that you can learn a lot from.
On the last point: note that the frequency of code deployment is often a business decision, not an engineering decision. An engineering team may be capable of deploying often, but the decision to deploy a new release involves a lot of other teams as well (product, marketing, CX, etc.), so the actual deployment frequency doesn’t matter as much. What matters is whether the team can deploy at short notice if they have to.
Other things to consider that will impact your job satisfaction, but that don’t necessarily reflect a company’s engineering quality, are:
- How much pair programming is typical?
- How large is the organisation, and how large is each team?
- Is communication typically synchronous or asynchronous?
- Is work conducted in-person or remotely?
I think these axes are mostly about preferences, and the right choice is whichever makes you happier. At the same time, it’s worth thinking about what is negotiable and what is not, and staying open to new experiences: I thought I would dislike how much pair programming happens at Thoughtworks, but over time I’ve come to really appreciate how much I learn through pairing.
What about the tech stack?
I personally don’t think the tech stack matters that much in your first software development role. You can definitely lean towards companies that use Rails or Ruby as a core part of their stack, and you should probably stay away from overly esoteric tech stacks for a first job. That’s about it.
Restricting your job search to only Rails is unnecessary: most of your Rails backend knowledge is readily transferable to Django, Express, Spring Boot, etc as long as you put in the work. Most employers who will consider a bootcamp candidate will be aware of this and give you some time to learn the stack. The cost of learning a specific stack is just not that high compared to the cost of hiring a weaker employee, so if you are an otherwise strong candidate for the job, the tech stack is unlikely to be the differentiating factor.
Erring in the other direction and being too open to esoteric stacks is a bigger risk, in my opinion. For a first job, you don’t want to become pigeonholed into a niche. Early in your software development career, you should aim to stay in the broad middle of the tech landscape, using more common frameworks and technologies.
To get a sense of how popular a given technology is, you can look at the Technology section of the annual Stack Overflow survey. If the main components of a company’s tech stack are not on the “Most Popular” list, or are very low on the “Most Popular” list and are at the bottom of the “Most Dreaded” list, I would probably not choose that company unless there were other very strong reasons to do so.
When will I learn enough?
I hope it doesn’t surprise you that the answer is “never”.
The world of web development is vast, and the wider world of software engineering even vaster still. Le Wagon teaches you two things:
- a very basic skillset that everybody in web development has some version of: HTML, CSS, vanilla JS, and building an MVC backend
- how to learn by doing, day in and day out
The first skill is your launchpad, but that second skill is the real fuel that will maintain the trajectory of your software development career. Every time you are asked to do something you have not done before, it will be bootcamp all over again: looking up resources, experimenting, debugging, and expanding your comfort zone to be a little bit bigger than it was when you woke up in the morning.