How to graduate from an apprentice to a star developer — Part 1
This is for young engineers who are lost after joining a new job and want to level up and make an impact. Based on my own personal journey as a fresher.
So you’re a grad straight out of campus and just joined your dream company. You see folks all around you; high energy, talkative, opinionated bunch, talking evolutionary design, refactoring code smells and TDDing away at the speed of light. And you wonder, when will you ever be like them.
So here’s the secret. Every single one of them, was just like you when they joined.
Nope, they didn’t know keyboard shortcuts nor did they TDD like there was no tomorrow.
Neither did I.
So here are some key takeaways from my own experience that might be of help to every aspiring developer.
Confidence
First and foremost you need to believe in yourself for others to believe in you.
I see some graduates lose confidence when they join. They doubt themselves a lot. It’s understandable, when confronted with a totally different and dynamic environment from college.
But if you weren’t good, you wouldn’t have made it to the organisation in the first place. So stop doubting yourself. If you believe and back yourself, sooner or later others will start gaining confidence and trust in you.
A great way to gain and inspire confidence is to start off with small tasks and do them exceedingly well.
Aim for small wins. And many such small wins add up.
- In my case, I remember not knowing anything about TDD or design patterns, but one of the first tasks assigned to me was to figure out why a certain package installer was not working as expected. It was opaque to everyone else why the installer wasn’t going through. I loved solving problems and took it as a challenge. I went ahead and figured out how to enable verbose logging, went through the logs and figured out the issue all on my own. And that really impressed folks. Yes, small things matter!
- The other big moment was when I presented alternative design solutions to a more experienced and very opinionated colleague. I presented them tentatively as suggestions, not having enough confidence in my own ideas yet, but he liked it and actually accepted it. Later, everyone remarked how it was quite something to have convinced someone like him! Not that I had any good debating skills, it was just that the idea was good.
These small incidents gave me confidence and earned some respect amongst my colleagues, even when they knew my knowledge was way more limited than theirs.
Knowledge is Power
The most important thing to know is knowledge is everything. Absorb as much as you can. Listen. Engage. Ask. Listen more.
- Are you a book person or a blog person?
- Would you rather watch a video screencast than reading through a long article?
- Or would you rather attend a session by someone.
- Or would you prefer a one-on-one with a colleague you are comfortable with.
- Or is it a group debate that excites you.
Find out what works best for you.
For me, it’s books. Because I love how books start off gently by building fundamentals and gradually introduces advanced concepts.
Whatever the medium, don’t just learn the ‘recipe’, learn the fundamentals. It’s the fundamentals that will help when the ‘recipe’ doesn’t work.
A common query, “Aroj, I am not able to SSH! What do I do?” But why not? Is it a network issue? Is the DNS resolving? Is the port blocked? Is there anything even listening on that port? Or is the server down? Or is it a permissions issue? If you knew the fundamentals of TCP/IP and SSH, you will know exactly what’s the issue.
This investment in learning the fundamentals has paid me great dividends multiple times in my career. Specially when debugging hard problems.
Clean Code
Everyone can code. But why is it so difficult to write clean code? Why have long 100 line methods? Why not break code into functions? Why are the right Object Oriented Abstractions missing? Why is the class exposing all its internals and breaking Encapsulation?
Because it takes time and effort to understand and write good clean code. This book by Robert Martin is an absolute must read, https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Closely related is the art of Refactoring. Learn to identify the code smells. And then refactor them to clean code.
I absolutely devoured these books when I read them the first time :-)
Become really good at that one thing at that moment
We can’t be masters of everything. The mountain confronting every newcomer is how to learn everything. The trick is to become really good at one thing you have a strong inkling for and and have an opportunity for at that point in time.
- For e.g, if you are working on build automation, do a pretty good job of it and automate lot of tasks. Automating the build may not be as cool, but it’s a hell lot valuable and a big contribution to the productivity of the team.
- If you’ve been asked to work on Performance testing, then work hard to understand the basics of performance testing and become really good at it.
- If you’re working on fixing bugs, then don’t just fix the bugs; but leave the code in a much better state by adding test coverage.
I love programming languages. So I really focussed on learning C# and .NET very well on my first project.
Make uncool cool
You can’t always work on the sexy cool stuff. I’ve seen many developers complain about not getting a chance to work on the cool stuff and having to do boring manual tasks.
- I was tasked with setting up an environment, which was ‘boring’ to other developers. I made it a lot more fun by automating it and adding Rspec tests to verify that the newly provisioned environment was setup correctly. This brought down the time required to setup and verify an environment to few minutes from 3–4 hours.
A current project’s tech stack may not always be what you wanted to work on. But it’s still important to follow your heart and work part time on things that interest you outside of what the company demands.
- I loved Python, but my first project was on .NET. So I decided to bring them together by building a dynamic drop-in interactive console to debug deployed ASP.NET applications via IronPython (python on .NET).
On encouragement from my colleagues, I converted it to an open source project and put it up for others to download and use. And everyone appreciated how cool this feature was. Again, this was another moment which helped me gain respect and appreciation amongst my colleagues. I was just having fun. The rest was a bonus.
Pairing
Pairing is a great way to accelerate learning. Pairing is the single biggest advantage of working at a place like GO-JEK. The amount of learning in a single pairing session is hard to fathom.
Of course you should still do your homework and read up on things. It’s not a pair’s responsibility to ‘teach’ you. But he/she can guide you along the way. Take notes of things that need more reading up while pairing. Read up on them and then discuss them with your pair the next day.
This approach will be better appreciated by people than being expected to be spoon fed on everything. Your pair is also trying to get things done. So respect that and don’t expect him/her to spend all their time tutoring.
Pairing is great as a learning tool, but it can also be a very difficult skill to pick up. In the next part of this post, I will talk more about how to excel at pairing.
Feedback
We all need people who will give us feedback. That’s how we improve.
— Bill Gates
At GO-JEK, we have a strong feedback culture and we are really lucky to be in an environment where feedback is considered a very natural thing. It also helps that our engineering principles insulates us from criticism in hindsight. As our Group CTO enunciates — ‘every decision is right at the time it’s made’.
Keep initiating feedback and collect both good positive feedback and constructive feedback for improvement. Don’t ever underestimate the power of good positive feedback.
But do initiate it. Ask for it. Don’t wait for it.
A quick catchup with your pair at the end of the day is often the easiest way to ensure you are getting continuous and timely feedback.
One Step At a Time
It’s not an easy journey. If it was, it was probably not worth it. I don’t want to make this all feel goody and “you can do it” stuff. Neither is it climbing Mt. Everest. I have seen people give up and quit. But for the few who couldn’t do it, there are countless others who have succeeded. All it takes is time and perseverance.
It reminds me of a quote from this book on Kalpana Chawla, where she describes the advice she got on mountain climbing:
You have to take one step at a time and focus on that each step. If you look below, you may feel dizzy. And if you look above, you may feel disheartened and scared. But if you just concentrate on taking that next step, one step at a time, before you realise, you will have reached the top.
That’s all for now. Hope this gives you all a good idea of the things to focus on. In the next part, I will talk about more such skills to focus on.
—– – – - Reproduced from my GOJEK blog