For the past few years, I had the opportunity to mentor new joiners through different roles. In some aspects, I could see myself in them the same way I started years back: eager to prove themselves, jumping on the code and hacking around.
I tried to think about what I learnt the hard way since my first role in the tech industry and how could I help them learn the easy way.
I’m making a list of things I wish I knew / somebody told me when I started working in tech. What advice would you give to your young self?
— Benoit Pasquier (@BenoitPasquier_) July 20, 2021
Take your time to learn
In my early days, I was all about hacking around. French education is unfortunately not known for their excellence teaching English, so going through pages of documentation in English was foreign to me.
I thought naively I could work around without this guidance. I learnt coding without it, how hard could it be? It was about trying again and again until I figured things out.
My approach was plain wrong, coding is not a guessing game. Taking more time to consolidate fundamentals make you a much better engineer. Unfortunately, most documentations are in English today, so non-English speaker will have to grasp this before getting to the meaty part of the learning.
The same applies to some Computer Science fundamentals, like algorithm or data structures. Some could naively think this is only required to pass grades at university but it’s missing a big point: most coding problems can be reduced to known algorithms or data structure.
It’s also a very common subject during technical interviews and believe me, it’s quite hard to get back at it when you miss it.
It’s important to have strong foundations, it’s like a set a tools, you’ll know which one to use when you meet a problem. You’ll avoid a lot of bugs and the frustration that comes with it.
It’s okay to not know
I met young engineers who were anxious not knowing “everything” for a role when joining a company. So let me tell you something: learning is a big part of the job, the technology changes way to fast to be able to catch up and know everything.
I believe that’s why so many engineers share their knowledge and findings through blog posts and books, it’s to help others catching up.
So not knowing “everything” isn’t the problem, the key is to know how to find the knowledge you’re missing. Lucky you, knowledge has many forms those days.
I’ll pass on Googling - digging into StackOverflow answers, but what about the language documentation? Is there any technical books you can get access to? Any videos available on the subject from previous WWDC or Youtube? Maybe you’re lucky and there is a Podcast on it?
Nothing found? Don’t give up just yet. You can try and try again to learn by yourself and don’t be shy asking peers to.
Re-learning is the skill that will help you go through any jobs.
On the other hand, don’t be lazy either. There is a difference between trying to find the answer and not looking for it at all. People notice this kind of things, it won’t help you.
Focus on your craft, not your job title
When I started, I felt job title meant everything. How great would it be to be senior software engineer, or staff, or manager or even CTO? I spent too much time worrying how to progress within my organization instead of focusing on my skill set.
Don’t get me wrong, job title matters, but it doesn’t matter as much as you think. Here’s why.
First, every job title depends of the company you are part of. Each organization has their own career evolution and measure progress differently. Being an “iOS ninja” won’t have the same meaning in your next job, you get my point.
Second, your job title can evolve quite fast early on in your career. Moving from junior developer to mid could take you couple years, maybe less. Don’t expect the same speed later on. Each title comes with responsibilities and expectations, some takes years to learn and master. So once again, take your time.
Challenging yourself to extend your skill set and demonstrating it your knowledge on you day to day job is more important in my opinion. People notice those efforts and eventually, your title will reflect that.
It’s same as running, focus on your form rather than your pace. When you’ve acquired a good technique, the speed will follow.
Best practices doesn’t mean latest trending tools
Over the past 10 years, the development tools have evolved a lot. We saw new tech and tools improving our day to day work. We saw new dependency managers, new debugging tools, memory management graph, functional reactive programming coming in, and so on.
I noticed a lot of developers focus on the tools more than understanding how it works and why some became best practices. For instance, iOS development went from an overly used MVC architectural pattern to MVVM with protocol oriented programming and dependency injection.
But why MVVM is so great? Why do we use dependency injection? Those are only a solution to support some best practices, like separation of concern or testability of your codebase. The same solution has trade-off and won’t fit all purpose.
Having a better understanding of development best practices and how some tools and design patterns support them will be me much more valuable in long term. It will be the compass to give you a direction, so when the ecosystem will pivot to a new tech or latest tool, you’ll still be able to gauge the value of it for your project and understand the tradeoff.
On the other hand, if you pivot your codebase every 6 months for a new framework, chances is you won’t find the stability you’re looking for.
At the end of the day, in my opinion, learning and re-learning is a skill that takes time. There is no shortcut to become a better engineer, focus on your craft, take your time to understand what you’re doing and this dedication into the details will make the difference. Eventually, it will pay off and open any doors for you.
Happy learning 📚