Boosting your career as a developer
This month is my 4 year anniversary of my first job as a developer. During this time I’ve had multiple jobs (startups, big companies and open source projects) and changed countries and continents. I was able to learn a couple of things that helped me improve my career and I wanted to share them as a celebration of my anniversary and everything that came with this new life.
Some of these can be quite obvious to some people, but time and time again I talk to people and find some usage for some of the most “obvious” tips. It is also missing a lot of stuff. It was already too long as it, but I wanted to share it anyway! So here is my celebration post to my 4st anniversary as a software developer! 🙂
Learn at least one technology deep enough
In today’s world, it is quite the norm to be lost in a sea of information and technologies. A new trending language or framework can be found each week. Tales of dead languages are told left and right. In my opinion, you should have at least one “pet” language or technology to know deep enough. And the key word is: enough. You’ll never know everything about a single language, nor should you. You should know enough to have a good performance with it but not be trapped on studying it forever and never moving on. Having at least 1 technology that you actually know proved to be much better to me than superficially know a bunch of them.
Because you know at least one language deep enough, you can handle yourself in cases of urgency while still being able to use your base knowledge to scale and correlate with the more deep technical stuff in other technology. You’ll be able to know deeper things and tricks, which will then make you look for those tricks on the new language you are learning. “If it is easy as that on language A, how can I make something similar on language B”?
Learn how you learn best
People learn in different ways and at different paces. I know people that learn better by trying and failing, and people who prefers to learn the theory before practice. I learn better when I write. That’s why I have tons of notebooks with actual code in it. Sounds crazy for some people to write an example on a real notebook, but I learned so much by doing that! I also can’t handle reading deep, technical books. I prefer looking for contents and chapters that interest me than trying to read a book cover-to-cover. Discovering the way you learn is essential to developing yourself in the fast and best way possible. Technologies change a lot - learning how to learn is a fundamental skill.
Improve your knowledge on design systems
Knowing well a language or a framework is useful, but it doesn’t give you the big picture on how things are developed in the macro cosmos. Understanding how systems are designed is fundamental to improve the way you develop new features, makes you think of corner cases and makes you question your most basic assumptions when facing a bigger challenge. It doesn’t mean you will develop a system from the ground up, but it helps you improve the way you think and the way you code. One of the most marvelous moments I’ve had was when I had a way of implementing things that never considered some things and someone more senior was able to teach me how this small changes could impact the whole system.
And the cool thing is that it is not so complicated to study them, since you don’t have to dedicate hours and hours of intense studying and code. You can either find books like Designing Data-Intensive Applications or channels in the YouTube that teaches how systems of the major applications we use are designed.
Teaching as a tool of learning
One of the best ways to cement what you learn is by teaching others. Some articles have found that:
Students enlisted to tutor others, work harder to understand the material, recall it more accurately and apply it more effectively.
Finding reasons to teach others is an excellent way of improving your skills. But not only that. To teach others you need to develop some soft skills that are fundamental to boosting your career. You need to have patience to go on the rhythm of another person. You need to be able to explain the same thing in multiple ways, to adjust the content to the different ways people think. It demands you to adapt, to rethink what you’ve learn - all skills that are valuable on an everyday-changing world.
The ways that I could think on teaching other during my career was:
- Give a talk
- Give a tutorial
- Do a study group
- Write a blog post
- Mentor someone
No mater how beginner you are, there are always someone that knows less than you about a subject. You should do it in the way that better suits your personality and life style.
Learn to sell yourself
As I wrote in a previous post, learning to sell my skills was one of the most important - and difficult - things that I had to learn to succeeded in changing careers. In an ideal world, people would recognize your work and abilities without requiring any sort of “marketing” being done. But we are not in an ideal world. You need to learn how to do that. I’m not saying that you should lie to make it better. What I am saying is that there is a high change that you are underselling yourself and the things you’ve done.
To make it easier to visualize that I created an exercise. I am going to present 4 situations that I want you to think about. Try to find similar situations you have gone through in your life. Think how would you present them in an interview for a new job that you really want.
The four situations are:
- A performance refactor was needed in the system you work on. You did 80% of a job but required help from your co-workers.
- You did a meeting with a client that is critical to your teams development. This is a big client and they signed the deal.
- You were responsible for defining how a small (but important) change would be implemented on the code. A major client request this change. You were able to finish it in time.
- You and your team organized an event to promote a new tool/project you have been working on.
Think about them.
.
.
.
.
.
Here is how I would see as a bad way and a good way of presenting each of the situations:
| Context | ⛔️ | ✅ |
|---|---|---|
| A performance refactor was needed. You did 80% of a job but required help from your co-workers | We did the work of increasing performance on the system. | We needed this task done to improve the performance of the system. I implemented the changes, being helped by Bob and Lia. The result was a 10% increase speed of the system, which means 100 more requests per second. |
| You did a meeting with a client that is critical to your teams development. This is a big client and they signed the deal. | We did the meeting and they bought the product. | I went to the meeting with the client on Monday. We had prepared a presentation with results of the impact of our products in different clients. They liked and eventually decided to sign the contract. That was a good win for our team. |
| You were responsible for defining how a small (but important) change would be implemented on the code. A major client request this change. You were able to finish it in time. | I wrote a proposal document and then I implemented the changes in time. | I was responsible for making this change on the code. To make sure everything was good as expected I did a proposal document to validate my approach with the team. Afterwards, I implemented the changes, with additional testing and documentation. The implementation was successful and we could deliver the feature on time. |
| You organized an event to promote a new tool/project you have been working on | We organized an event for the new X tool we created. | My team and I organized an event to promote and incentivize the use of X tool we created. I was the main organizer, responsible for the coordination of the multiple teams involved in the process. The event had 120 RSVPs and 60% of attendance on the day. We had 3 questions for the audience and the downloads of the tool increased 5% after the event. |
As you can see, you can create a straight forward answer that simply tells you what you did, but this doesn’t tell the whole story. The best way to do this is to tell the story in the format: situation, action and result. You start by telling the context: I was responsible for making this change on the code. This contextualize what was going on and your role in it. Then you tell how you acted considering your role in this: I did a proposal document to validate my approach […] I implemented the changes, with additional testing and documentation. Finally you present the result you got via your actions you’ve done: The implementation was successful and we could deliver the feature on time.
Another thing is that you will forget about those achievements. Trust me, you will. So write a Brag Doc. Write what you did in the format situation-action-result and keep it updated. Make sure that you update it at least one time a week or every two weeks - but that you update it! You can also share it first with your friends and people you trust. But when time comes that you need to be sure of everything you did do NOT hesitate to share this document with your peers and your manager.
Learn to negotiate
Negotiation is an art and it can be used anywhere. Even in life in general, we are always dealing with scarce resources: limitation of budget, limitation of people, limitation of time. You need to able to talk about limitations and deadlines. You need to able to say “no” and how to compromise in a middle ground. If you don’t learn to negotiate and to explain your point of view you’ll end up with deadlines you can’t meet and promises you can’t keep.
Part of being able to negotiate is to understand what is the root problem the other person is trying to solve and to see if the thing they are asking is the same thing that they need. You need to understand that to propose a smaller thing that can solve this problem, or compromise in extending the deadline to get better results. Negotiation is a major skill that is very underrated.
Do not jump to management tasks too early
There are ton of work besides coding that are extremely relevant to a tech team: writing documentation, reviewing document, writing notes in meetings, onboarding new people, improving processes, etc. Tanya Reilly calls this glue work. As she wrote on the amazing article: those skills are expected from senior engineers but it can be harmful if you are staring your career.
This is true specially if you are a minority in tech. Trust me, it happened to me. I was managing a third-party team, being the lead for the backend, talking to the Project Manager about requirements, etc. But when I asked to be promoted I received a “no” because I was too junior for that. As a minority in tech, people don’t expect that you are a technical person. And because of that, you should do the work that get you promoted and get you where you need to be able to do the tasks you enjoy no matter what. So even if you are really good on those non-technical skills, avoid them at the beginning of your career and focus on tasks and skills that can advance you technically - and thus being promoted.
Don’t loose opportunities because you don’t think you’re ready
The true reality of life is that nobody actually knows what their doing. The truth is that if you are 100% sure of what you are doing, you are probably not learning enough and you are probably in your comfort zone.
The vast majority of our learning happens on the job. (Tanya Reilly)
So don’t wait to know everything to go after the job you want. If you know everything for the job you want, you probably are too good for it.
This is me in most of the things I’m doing
If you see a job description for something that you have always dream to work on, apply. You may have no chances of achieving it, but you should try. Always. You shouldn’t do the job of the people who choose. It is their job to see if you are good enough. Your job is to apply and do your best.
If someone offers you a role in a new exciting project that you have no idea if you are good enough, take it. If they invited you, they think you are good enough to learn and do what needs to bee done.
If you’re offered a seat on a rocket ship, don’t ask what seat! Just get on. (Sheryl Sandberg)
It is not easy to develop all this skills. I am pretty sure I need improvements in all of them and every day I learn something that I need to improve or that I developed in order to improve myself. Some occur to you more naturally than the other, some may take all your strengths. Don’t worry, you will get there eventually! Trust in yourself, be patient with the things that are harder and be kind to you and your time. Everybody have their struggles 🙂
❤ Cheers! LetíciaKeep going up: you may never reach the top but at least you know you are in the right direction