Jesse, an Apprentice at Build Labs
I joined Build Labs because mentorship is critical to me. I’m still new in the field of software development, and being able to learn from people who have lived it for years is an amazing opportunity. In my former career, I was the only one in our organization who performed my role, so I didn’t have anyone nearby to correct my mistakes.
Of course, there are plenty of external avenues to advance your skills, but it’s entirely different from learning on the job and building meaningful projects for your clients. So with that, here are a few things I’ve learned from my peers and mentors at Build Labs.
I’m fortunate to have the opportunity to explore new tech stacks as part of my job, especially ones that are hot in the market right now (per our clients’ interest). One of the most significant fears of new coders is, “what if I’m learning the wrong thing?”
Don’t fall into the pit of analysis paralysis because you’re worried about wasting time – just learn something! Software development is highly transferable between languages. Once you understand the basics of creating something, languages and frameworks simply become tools to help you build them. The only difference is (mostly) syntax.
Having said that, try to keep track of what you enjoy. Do you like web development? Maybe you prefer backend stuff or DevOps. Maybe you even want to get into cybersecurity! Try to figure out – in a broad sense – what you might want to do with your career in the tech space. If you can answer that, the technologies you should be learning will become much more apparent.
Every development team that’s been around longer than 5 minutes will probably have a set of coding standards. These conventions are typically a set of internal documentation that provides guidance to developers on how code is created at the organization. The guidelines can include things like naming conventions, indentation, error handling, version control, and much more.
The value of having coding standards is improved readability and especially maintainability of the codebase – if everyone writes in their own style, the codebase is going to turn into a spaghetti-filled nightmare real fast.
Many new devs tend to think they’ll follow all the rules and best practices and write perfect code at their new job. Spoiler alert: things go a little differently when you have tight deadlines to meet. This isn’t meant to dissuade you from writing excellent code; on the contrary, I encourage you to do your best and develop good habits. Just don’t be too hard on yourself when you eventually have to cut some corners and swiftly duct tape together an abomination of a solution because a stakeholder needs some changes right before deployment.
A core concept in software delivery is the idea of the MVP – minimum viable product. That is, what’s the least amount of work to get the product to an acceptably usable state? Software development has a massive upper bound for complexity and it’s easy to get bogged down in the details – pretty soon you’ve spent weeks on a project with nothing to show for it. When you have deadlines, just focus on the MVP, design a solid backbone for your project, and refactor it later if necessary.
There’s a mythos in this space surrounding the lone-wolf master hacker who’s a genius but has antisocial tendencies, lending credence to the idea that the better you are at programming, the more of an a-hole you get to be. If you aspire to be that person, I have some bad news: you’re not cut out to work in this field.
Software development is first and foremost a collaborative effort. Even Linus Torvalds knew that when he made Linux an open-source project. You can be the biggest rockstar in the world for your niche, but if you’re difficult to work with, no one will hire you.
Exhibit A: Allegedly Google passed on hiring the creator of Homebrew because they’re difficult to work with. The same Homebrew that is the package manager a vast majority of Google engineers currently use.
The biggest advice new devs tend to receive is “don’t be afraid to ask dumb questions.” I’d like to add a caveat: don’t be afraid to ask dumb questions after you’ve already exhausted all other avenues to solve the problem yourself. Have you checked the documentation? Have you checked Stack Overflow? Have you checked the company wiki? Have you checked some obscure blog post you found through a google search that contains the exact error message you’re getting?
As a developer, you’ll run into roadblocks constantly. It’s part of the complexity of the trade, and it’s why good devs get to make the big bucks. They’re great at problem-solving, they’re persistent, and they know how to find answers to the questions they have.
While your senior dev will likely be more than happy to help, when they’re swamped, and you come to them with a question, the first thing they’ll ask is what you’ve already tried. If you say “nothing yet…”, you probably deserve the look of frustration (and sometimes profanity) that follows.
Learn how to use git. We’ve all heard horror stories about the junior dev who accidentally pushes something to production, and then the universe explodes – these kinds of errors can be avoided with good version control! Here are just a few things to keep in mind:
Start learning version control best practices as soon as you can to develop good habits, and with some luck, you won’t destroy the universe – or anything in production.
If you’re a new dev like me, you probably recently spent hundreds of hours on the journey of learning how to code. Well, keep it up! Compared to most industries, software development advances at an incredible rate, and new technologies are constantly being created.
If you don’t want to be left behind, you should make it a habit to keep learning. It doesn’t even have to be a new language, it could just be a framework you don’t know, a CSS library you haven’t used before, etc. There’s always more to learn, and the best part is that the more you practice learning as a discipline, the better you’ll get at it.
I’m still just a junior dev. There are a near-infinite number of things I don’t know about software development yet, and a good portion of them I’ll probably never have the opportunity to learn.
With that in mind, these are just a few of the things I’ve found to be important in my first year. If you’re a new dev, I hope my lessons can help you. If you’re a senior dev, can you take a look at this weird bug I’m getting?
