DEV Community: Diogo Costa

Yes, you should do a coding bootcamp!

Diogo Costa — Sat, 01 May 2021 14:05:15 +0000

Disclaimer: I have treaded the bootcamp path myself, to switch careers into web development in just over 6 months.

This is a question I keep getting: "should I do a software development bootcamp?"

For clarity, I'm going to assume anyone who asks that question intends to become a professional in the tech industry, and they mean a bootcamp as opposed to a CS degree or self-teaching.

The short answer is: yes, you definitely should! You are leveraging the most valuable resource of all, which is time. So you can stop reading here and go learn, or better yet, sign up to any reputable bootcamp, and thank me later! But if you'd like to continue reading, let us expand on this topic.

Bootcamp vs a CS degree

Often, people will argue that a Computer Science degree teaches so much more, and graduates get better-paying jobs. And that is undoubtedly true.

However, the enormous benefit of 3+ years saved, amongst other minor ones, vastly outweighs that of a comprehensive learning approach.

The reason for this is that Bootcamp grads will be employed anyway, albeit in a more junior role, shortly after they finish the programme. So we are talking about 3+ years of work experience and salary.

But what if I don't find a job, you ask? Well, if you're even semi-competent, someone will hire you - it's that simple. This is a consistent outcome of several different coding bootcamps (see examples below on Flatiron School and Le Wagon, respectively). It's also the reason why many schools will allow you to pay nothing until - and unless! - you become employed.

Think about that - if you sign up for a bootcamp today with zero experience, then between prep time, bootcamp time and job hunt you will realistically be working in the tech industry within 6-8 months.

Someone starting from zero, who has never seen Hello World code before, will likely start in a very junior position. That's OK! For many people that still means a salary greater than they were making for years in other lines of work, and by the time they put 3 years in, their learning will have been far more significant than that of most CS students. You might be making 6 figures on salary alone.

I once heard it said that you learn 30x faster on the job vs school, and I don't think that's too exaggerated.

The other advantage is the cost. Time, beyond being valuable, is also costly for many. Take my experience as an example: stopping my professional life to pursue an intensive bootcamp cost a lot of money. I was in London at the time, and in the 6 months I spent just studying and then job hunting, I had to pay rent, childcare and expenses, and commit to the exorbitant (albeit deferred) bootcamp fee. It set me back something like £40k, perhaps more, which built massive debt at the time. And mine was a 3.5 month programme! I managed to do it because I had support, between loans and family, but even for a privileged man such as myself, it was simply not an option to sustain a monthly spenditure of £4-5k for 4 years.

Finally, I would like to acknowledge the unique value of a CS degree. Highly structured learning, the covering of all bases with things such as computer architecture, lower level languages, security, and even non-CS topics like Physics and Calculus, all ensure the student becomes a more well-rounded professional. And the network and relationships built over 4 years are also incredibly valuable - this can't be matched in 3 months with a bootcamp cohort.

But a lot of these things are not out of reach for a bootcamp grad - you can choose to spend some of the time you saved by studying on your own, with the benefit of knowing what you truly need to learn for your professional goals.

So while the CS degree is a worthwhile investment for those with zero monetary cost - which is a thing for many middle class young people still living with their parents, for example -, I would still recommend the bootcamp path for all the focused learning, saved time and flexibility of choices post-programme.

Bootcamp compared to self-teaching

With all the content available online, much of it for free, it's entirely possible to go from zero to employable by yourself, in your own time and pace. And this is an incredible possibility for those that cannot get their hands on enough money to pay for formal education.

But if you can sustain yourself for up to a year while pursuing the bootcamp path, however, I 100% recommend you do so.

There are some key benefits here that have everything to do with human nature and, again (as ever!), the value of time.

Firstly we have the value of a well-defined curriculum. It can be daunting, discouraging and ultimately deal-breaking to be faced with so many languages, frameworks and fields of software development out there. Should I learn Python or Javascript? React or Vue? Can I even call myself a developer if I don't master VIM? And what the actual fuck is dependency injection?

The bootcamp curriculum removes all of this mental overhead, allowing the student to focus on learning what's in front of them with the confidence that they will be job-ready by the end of it.

Secondly, it's incredibly hard to emulate the environment of a bootcamp. You are surrounded by like-minded people with the same struggles and ambitions, with whom you can even share some healthy competition (and the occasional beer in times of despair!). You also enjoy the support of instructors to get you that little push that you need to get unstuck.

Thirdly, and this is just how us humans function, you're just more likely to get off your ass and do the work when you have to be somewhere at 9AM and sit there until the day is over. It's more like 8AM to 9PM by the way, if you're doing it right, but I digress. Additionally, you naturally want to prove to your peers that you can do this. Because let's face it: it's just too damn easy to take breaks or give up when you're doing it by yourself, and people end up taking 9 months or more with a curriculum they could have completed in 3 months within the bootcamp structure. So while this path will save you money, it will cost you time. Which is more valuable?

But hey, if you do have flawless discipline and a couple of developer friends that can guide your learning and tell you when you're ready for the job market, the self-teaching path might just be a good bet for you.

Some final thoughts

Remember that it's all about the effort the student is willing to put into it, regardless of the path you choose. Take the half-assed approach and reap half-assed rewards.

For me, that meant that from the moment I decided to study in an intensive 15-week bootcamp, I was all-in. I was going to learn all the things thrown at me, and I was going to make the most of my investment. Trust me, you don't want to spend 30% of your $15,000 course without having done all the prep work to know the basics.

A funny thing - finishing my studies and starting to work is a bit of a blurry time, because I just simply continued to learn on my own, and still do quite frequently, albeit in a more focused fashion.

The tech industry is very particular in that we all have to constantly learn to have a chance at levelling up professionally. I like that because it allows those who have the drive to really accelerate their growth. Though if you're into the sort of work that you can do mindlessly and just get small promotions over the years, you can totally still do that as a developer, so again - go and enroll in that bootcamp you've been thinking about doing, and thank me later.

Code Review: You don't want your PR approved

Diogo Costa — Tue, 06 Apr 2021 17:08:00 +0000

Good code review can be your team's superpower.

I love engaging with my colleagues to discuss pull requests, whether theirs or mine. One can learn so much, even (perhaps especially?) if there is a gap in seniority!

Conversely, when my work is approved without feedback, I am disappointed, because code review has consistently improved my understanding of the tools we all use.

It's about collaborating to improve the team's output - good code review is based on the acceptance that we all make mistakes, and that those are not something to be concealed but rather an opportunity for everyone to learn. Once you accept that criticism of your code is not criticism of you as a human, the constructive learning starts and oh, what a wonderful thing it is!

I always try to push my teams towards giving reviews the love they deserve, finding good habits and ultimately establishing a great process.

Why do we need a code review process?

Meaningful reviews are simply less likely to happen without having a process in place.

Teams that don't have one are at the mercy of the individual engineer's inclination to do it well, and without buy-in from everyone the ones that do will feel frustrated and tend to give up.

Similarly, others might feel that the process is too strict and simply avoid it altogether.

Another obstacle is how personal it can feel. Getting our work reviewed directly by peers may feel a bit invasive and foreign. Don't worry! That is totally natural, especially when coming from a career outside of tech.

Rules and guidelines help engineers navigate that feeling, and by establishing that the team wants to take review seriously, people can discuss ways to continually improve the experience, as opposed to debating whether review matters or not.

Goal of code review

"The primary purpose of code review is to make sure that the overall code health of Google’s code base is improving over time" - Google

Google's excellent notes on the review process define this goal, but what does it mean to "improve the codebase"? It's more than implementing a change that "works" - aspects like code readability and context awareness ought to be considered as well. If a feature works but introduces avoidable tech debt, a reviewer should request changes.

This doesn't mean PRs can only be approved if they are perfect! An "okay" improvement is infinitely better than no improvement at all, and a slow review process will harm your team's morale.

The golden side effects of code review

The article opened with this notion, but it cannot be overstated: reviewing someone else's code will make you both better engineers.

And how could it not?

We are exposed to different parts of the codebase, building domain knowledge;
We learn programming techniques and approaches;
We practice attention to detail and communication skills;
We sometimes do research to confirm whether a comment we are about to make is correct;
We are reading and interpreting code - arguably the thing developers do the most while programming.

Code review should be prioritized

It is tempting to think we can leave a review for later, but this mentality undermines the process.

If you would eventually review a colleague's work, then do it as soon as you can instead.

The benefits are clear: if work is "rewarded" with quick feedback, engineers are able to incorporate it shortly after they wrote the code, and a healthy feedback loop can be an addictive good habit. PRs should ideally go through multiple review rounds daily.

As a bonus, this fast process leads to features taking a shorter time to get to production - one of the biggest predictors of software teams' success.

Waiting a few days for a review, however, adds a lot of friction. Merge conflicts can arise in the meantime, our memory of the implementation deteriorates, context switching (the killer of productivity!) becomes more common, etc.

So while it can be tempting to put off that review until you're done with your own tickets, remember that your greatest strength as an engineer is not your individual output, but rather your impact in the team you work with!

A caveat - I don't advocate stopping in the middle of a coding session if a review request comes in. A good rule of thumb here is, if you have pending reviews and you're just coming out of a meeting, starting your day or back from lunch, always prioritize reviews before going back to your own work.

Strategies for a meaningful review

Be kind to other humans

Code review brings out our human nature a lot.

No matter how much we advocate for a healthy, blame-free and mutually beneficial process, it will still hurt to see our work challenged in the public eye and feeling we are not good enough. Because of this, it's exceptionally critical to be kind, constructive and positive in every comment we make.

I cannot stress this enough - failing at this will cause more harm than good, no matter how knowledgeable and right you are.

A great way to navigate this is the Is it true? Is it necessary? Is it kind? approach - if a comment you're about to make does not pass those 3 questions, consider deleting it.

Avoid perfection like the plague

Remember the goal of code review: improving the codebase.

If you find yourself spending too long trying to iron out details in a colleague's PR which is already an improvement to the codebase, then approve it instead. You're likely in the realm of diminished gains at this point.

Quoting from Google's guidelines: "Instead of seeking perfection, what a reviewer should seek is continuous improvement".

Be clear on what you are requesting

Label your comments or make it otherwise clear whether you are requesting some change / require an answer or merely making a suggestion that the author can disregard.

Challenge overly complex code

Code review is particularly powerful here: if you're having a hard time understanding the PR and can't make sense of it, it's probably going to feel that way to other devs too.

This is understandable. After spending days working on some feature, it's very easy for an author to understand their code much more easily than colleagues looking at it for the first time.

But complex or hard to read code being merged in is fertile grounds for slowing down future changes or bugs being introduced by the next developer, and as such it should absolutely be challenged.

The reviewer has an excellent chance to spot potential issues, for instance poor naming of variables or lack of comments where the next person has no chance to understand why something is implemented the way it is.

Review even when the author is more senior

This fear is so common, and yet such a misconception. If you regard someone so highly that you think your review isn't helpful to them, then you can at the very least learn a lot from just reading their code.

And I will let you in on a secret - even the most senior of devs introduces bugs, makes typos and misses simpler solutions! You're doing them a disservice by assuming their work needs no review.

Finally, as an experienced engineer it's very valuable for me to know whether my code can be understood by everyone, and less senior colleagues are best placed to give this feedback.

Point out context-based omissions

The complete engineer doesn't blindly follow ticket requirements - it's entirely possible that the team forgot to consider some aspects of a given feature, and with a strong understanding of your team's product you can add value by pointing these things out at code review level.

Similarly, as a reviewer you should be requesting codebase-level changes that become necessary as a result of the feature, such as the need to update the readme when appropriate.

Do not nitpick

Reviewers can sometimes be very particular around semicolons, code style, etc.

Learn to recognize when a change request is just personal preference, or whether it is truly valuable for the codebase - and then discard the ones that aren't.

A lot of this kind of feedback is better handled in a more productive, value-creation way: go and advocate for / create a style guide, or implement automated style and linting rules that everyone can benefit from, thus removing such discussions from the code review stage.

Strategies for submitting PRs that invite meaningful review

Use common sense

Do not submit PRs in a state that you yourself are discouraged to review when faced with.

The golden rule is to respect your reviewer's time.

Break your features into the smallest PRs you can think of

Break your big features into small PRs - a change to 32 files with 25,000 lines added will be reviewed by approximately zero colleagues.

This can be done by carefully considering what the micro-changes might be before attempting to write any code - and this has the additional benefit of giving you a perspective you might not have considered had you just dived into it in one massive PR.

Read what you are about to submit

Do a basic review of your own PR to catch any obvious mistakes like random console logs, commented out code etc. Small issues like that may seem minor, but they signal to colleagues that the PR author is rushing their changes through.

Use appropriate titles and descriptions

When submitted, your PRs should be titled appropriately, they should have solid descriptions that explain why they exist, and they should link to any relevant tickets or design briefs.

Most of the time, reviewers should be able to understand everything just from reading the PR itself, without the need to go and check the JIRA board or asking other colleagues why this change is done.

Engage with your reviewer respectfully

Avoid disregarding comments or change requests without explaining your reasoning. Doing so would undermine the process greatly - people are naturally less inclined to leave comments for a colleague who routinely ignores them!

Furthermore, if an issue arises where there is some disagreement, try to err on the side of the reviewer's opinion: they are, after all, more detached and that is a benefit when critiquing your implementation.

Now get out there and get reviewin'!

I hope these ideas can help you improve your day-to-day work, but by all means feel free to challenge them. Every team is different, and you should always question the rules in each interaction - what works when reviewing Janet's work might be a poor approach when dealing with Ricardo. Humans are unique that way.

Lastly, remember that scrutinizing other people's work in a public forum can be very upsetting if done poorly - some even advise against it altogether. As such, it is exceedingly important to be very sensible when approaching it, but I still wholeheartedly recommend you try to use this tool comprehensively. The benefits are immense and immediate!