Fitting in at your first job can be challenging. Often, there'd be no one to guide you, tell you right from wrong, almost everything you learn is on your own. Growing and improving in your first job, is not obvious either, it takes time and effort. I joined a team, that guided me and provided me with an environment to learn, grow and have fun along the way. I learned many things in my year long journey, and I wish to share some of them, hoping that it helps the newcomers of tomorrow.
Lesson 1: Don't be afraid to interact.
If you're an ambivert like me, you may try to avoid unnecessary social interactions as much as possible. The ambivert (or introvert) in you will cause you to incorrectly think every non-work interaction is unnecessary. It's a bias, don't give in to it. Through some of the most awkward 'Hello's and 'Nice to meet you's I've met some of the brightest minds at my workplace.
When you start talking to people and find out their interests, ideas and stories, you make connections you'd be truly fond of. It will make your work life a bit less boring and more importantly make collaborating an exciting activity.
I made friends with an engineer who loves teaching, maintains an awesome tech blog and loves travelling. I learnt a lot about Java from him, and helped him with JavaScript where I could. We worked on complex tasks together. It was satisfying to collaborate with someone with so much experience, and I may never have had the opportunity if not for the awkward 'Hi how's it going?'.
Lesson 2: Stick to your work schedule.
I knew it's a bad idea to take your work home, but disappointingly, I would find myself working on tasks at home, every other day. It was just bad planning on my part that contributed to this failure.
Eventually I adopted a different model. I plan a schedule when I start my work day, evaluate how much I've completed at the end of the day, adjust my workload for the next day based on how much I can complete and repeat this process. This worked for a while until I started taking up ad hoc tasks, during the middle of the day, failing to complete my planned tasks for the day.
Enter priority based task handling. My planned tasks were my highest priority, I picked them and sorted them based on my capability to complete them and how impactful they were. Ad hoc tasks pop up a lot in an agile team, they are good, it's the mechanism to continuously steer clear of obstacles, and stay on the road towards the bigger goal. But they messed up my daily plan, so naturally I deprioritized tasks for my original list, to make space for the ad hoc task. This is working for me even a year later.
Assigning priorities is a mundane process, but it benefits me in the following ways:
- I rarely take work home, so I have time at home to spend on myself.
- I feel good about ticking off all my tasks for the day. I am able to see myself grow when I complete more complex tasks quicker.
- It improved my productivity, and therefore the team productivity.
- I got pretty good at judging priority, which is an essential skill in and outside work.
Lesson 3: Stick to your learning schedule.
If you read the previous lesson, you'd appreciate the value of a schedule. In the world of software, no one knows everything, and the rate at which new information pops up is overwhelming, so how do you keep up with all the new frameworks, languages and best practices.
You don't. You can try to adopt the T-shaped learning model. Simply put, it's when you learn to become an expert at one thing by researching and acquiring deep knowledge, while expanding your knowledge across various subjects.
I enjoy learning about the web, so I dived into front-end development with React, Angular and experimented with some other frameworks. The more I worked, the more I realised, how important understanding JavaScript (ECMA Script) was to becoming a good front-end developer and building client side application, because all good UI frameworks, do the same thing: build wrappers around JavaScript's core features to expose APIs that make the developer's life easier.
So I spent a lot of time reading and understanding the fundamentals of JavaScript, tinkering with experimental JS features, using advanced concepts at work, all in order to improve my mastery of the language. This helps me work with modern frameworks better, debug faster and justify my technical decisions. In addition, I continue to learn more about how the web works, how online payments work (My team is working on a payment gateway) and cloud technologies.
My T shaped knowledge on software might look like the above.
To do this effectively, I put in six hours each week for six months to read, code and discuss JavaScript with experts. 1 year later, I can work with advanced concepts like closures, promises and async functions with ease. I'm not an expert yet, but I'm progressing steadily.
Figure out what you'd like to learn by actually trying everything you might like to learn; you'll eventually find out what you are most interested in. After that work out a study plan, invest time, subscribe to resources online (paid or free) and work your way through it.
Lesson 4: Challenge your peers.
As a junior working with people who have more experience and knowledge can be daunting. It's normal to feel like you should have less say, but it's wrong to follow through with that feeling.
You're depriving yourself of opportunities to learn if you never challenge your peers. Sticking to my learning schedule helped me understand JavaScript as a language really well, why it was made, how it was supposed to be used and what are some common pitfalls.
We use AWS Lambdas at work to offload asynchronous tasks, which was a neat idea. The code written (in JavaScript) to do it, not so much. I raised questions about efficiency, complained about code quality and eventually asked for a chance to work on it to make it better. It didn't go exactly as planned, (we still have Lambdas written with bad code, more on that later) but some good came out of it.
- The team appreciated my growth and my ability to point out mistakes.
- I learned how to communicate my thoughts better, especially on tech. It's not easy to get your point across all the time, which is why it takes practice.
- Asking 'Why are we doing this?' helped me understand the system better, allowing me to be a contributor the next time we were designing new features.
Start with a simple "why", at your next meeting. It goes a long way.
Lesson 5: Do Effort vs Impact analysis
As a software developer you put effort into solving problems that have various levels of impact. Sometimes you're changing the colour of a button, sometimes you're integrating a fraud detection mechanism into an online payment flow.
It's important to decide how much time you'll spend planning/working on your task, before you get started on it.
Changing the color of a button, has comparatively less impact on the user experience, than integrating fraud detection. It is also easily undoable, however undoing an integration from the user journey is not easy. Therefore, spend less time planning and discussing the color, instead push the change and wait for feedback from the customer experience team, to decide how you'll improve.
However, if you integrate fraud detection without proper planning, you may break existing user experience, face new bugs, and may not even achieve your goal of preventing fraud effectively. In this case, it is worthwhile to test the integration separately, discuss edge cases and spend time building experiments. These experiments maybe throwaway work, but it may save you from costly bugs and frustrated users.
When my team wanted to integrate a third party fraud detection API, I spent time writing SQL and Node scripts to test the software in an isolated environment. We may never use the code I wrote, but it helped uncover that we were missing some key pieces in our flow required for fraud detection. If we didn't realise this this integration would have been a costly mess.
When given a problem, before you plan a solution, think of the impact solving it will have on your users. Plan your effort with respect to this impact.
Lesson 6: Take up teaching
It's not only the best way to give back to the community, but also a great way to validate your skills. I've always loved teaching other, so I was fond of teaching others at work.
Through teaching, I improved how I communicate complex concepts, and when people ask me questions to which I don't have an answer, I'm presented with an opportunity to learn more. Through a cycle of learning and teaching, I improved my React skills rapidly.
In addition, you also build meaningful connections with your team members, when you play the role of a teacher. You build trust and gain opportunities to collaborate on exciting problems.
As a teacher you're not only absorbing knowledge but also disseminating knowledge, which helps your team to trust you and eventually gain opportunities to work on exciting and novel problems.
As a new member in the team, it might seem impossible to start teaching others, but your fresh perspective on the system and the free time you have helps you build knowledge that others might need desperately. Use this opportunity to try to teach something, however simple it is.
Lesson 7: Don't fall into imposter syndrome
The world of software is filled with popular, influential and talented people. I've felt insufficient after seeing developers who own GitHub repos with over 1k stars, write consistently, brag a huge following and rank high on Stack Overflow, while I hadn't answered a single question until recently. I sank into a feeling that everything I know is trivial and I could be easily replaced. I compared myself to people I didn't even know, and felt bad about it. This feeling is referred to as Imposter Syndrome. The right way to deal with these feelings is to have better perspective.
The high performing developers you see online, didn't get there in a day, they worked hard for it. What you need to do is not feel bad about your efforts, but work on improving yourself. You've done a good job so far and you have more to go.
On that note, remember to take care of your physical and mental health, more often than you take care of career.
These lessons definitely aren't all the answers to shaping your career, but it should get you started well. In conclusion, your first job (in software) will be filled with challenges and opportunities. Learn to pick and choose wisely, take it easy on yourself when you make mistakes and have fun along the way.
No one has the right answer to everything, so don't be afraid to try what you like, and create your own identity in the complex world of Software Development.
If you liked this follow me here and/or on Twitter for more of my thoughts on software.
Latest comments (0)