Introduction
I have seen a lot of posts on how to get your first job, but very little blog posts on what happens after that. There is so much information to absorb when you’re just starting out, and admittedly I have learned a lot.
Full disclosure, this is technically not my first role getting paid to write code, but it is my first non-contracting role where I actually get to work and build upon a product! I’m excited to share what I’ve learned and hope it’s useful to you!
Code
Value of Testing
The act of writing test is talked about so much I won’t even bother to go into it, but using the tests themselves is another story. The sheer amount of confidence I gained when I saw our tests suite is ASTRONOMICAL! The tests suite gave me the confidence to do whatever the fuck I wanted to the code without fear of breaking any already implemented functionality when I received my first ticket. I would run the tests after every commit, save, or for any changes at all. I mean why wouldn’t I? It’s basically free and takes nearly no time at all! It was pretty empowering, and has only encouraged me to write test for any future functionality that I add to our product.
Use Your Codebase for Clues
Your fellow colleagues want you to succeed and will help you in any way they can, but they won’t be holding your hand every step of the way. The codebase is an extension of your colleagues and you can use their code as clues. Clues for formatting or conventions. You can do a full text scan on the codebase to search for examples of let’s say SQL queries or multi-threading. Look up specific files like controllers or components to make sure you follow certain patterns. If you’re unable to find something you could even ask a colleague to send you examples of let’s say pagination, so that you don’t have to take up more of their time than you have to. And, if you still need further clarification your colleagues will always be there (probably more willing to help now, knowing you’ve tried to figure things out on your own).
Don't Trust Your Codebase (blindly)
This may seem counterintuitive to our previous point, but I promise it’s not (at least not entirely counterintuitive). I noticed my coding style changing in every class or file I was working on. I was subconsciously trying to keep things consistent with what was already there. This may possibly be a good thing such as file naming conventions, like naming all asynchronous tasks files by appending the word job. But, it may not be the best idea for core engineering practices like the use of global variables or undescriptive function names. Working on some legacy systems you are bound to find some shitty code. The new code was much easier to work in and followed best practices, but I just kept falling into bad habits when I was surrounded by the shitty code. So, no you don’t want to blindly trust your codebase; don’t follow bad practices just to be consistent and don’t be afraid to refactor if it’ll save you time and sanity in the long run.
Beyond Code
Communication
Communication is a vital skill for any occupation, but it seems increasingly more important for software engineering. As software creeps into every industry, collaboration between engineers and other professionals seem to grow at a rapid pace. Truth is, it’s easy to get lost in our world of software engineering and loosely throw out sayings like API as if everyone outside of engineering knows what an API is. We engineers’ need to do better at explaining our own jobs. Make sure our customer support representatives know when or why our site was down for 30 minutes so that they could be do their jobs when they inevitably get flooded by support calls/emails.
Second, as juniors we could probably do a better job at communicating our technical know-how to other engineers as well. Things like system diagrams, UML, technical documentation, and flow diagrams are things I have practically ignored during my job search and seems like something that’s very easy to gloss over.
Team Rapport is REALLY Important
I joined a really small company, so I feel like it’s really easy for me to say how important rapport is to the success of my team. But, this advice extends to larger companies and to the interview process as well. While you may be in a 10,000-person company, your team is likely not more than a dozen people. If you’re fortunate enough to actually meet your team during the interview process (not restricted to HR and hiring managers) this is the perfect time to sniff out how you actually fit with these group of people and potentially start building rapport.
To keep this short and simple, when you have team rapport you actually start to give a shit, and when you give a shit you do some of your best work. Doing your best work, I hope has self-explanatory benefits (like being more likely to be promoted, more likely to improve, and more likely to actually enjoy what you’re doing).
Speak Up! Be Candid
I feel like junior engineers tend to believe that our lack of experience somehow makes our input less valuable. After two months of meetings, being probed, and giving input; I believe it’s the contrary. As juniors we might have less input, but it could be more valuable. Having fresh eyes is like a super power, you can give new insights by approaching problems in a different way or even being able to give unbiased opinions.
- When asked a question, answer it. If a person did not care for your opinion they would not have asked.
- Don’t be afraid to say ‘I don’t know’.
- If you don’t know something, ask. A lot of times companies/teams have their own jargon, and it’s probably a good idea to know what your team is talking about.
- Question everything. Why are certain things done? Do not accept, ‘because it’s always been done this way’.
- Don’t be afraid to ask for help.
I’ve been in a very fortunate position where my team is not only open to hearing me out, but is actively trying to get my input. It’s only been two months and I have already improved some of our processes.
Low Expectations for Juniors
Expectations for junior software engineers is pretty damn low. This feels almost like a taboo topic to speak about, but I think we can use this to our advantage. Impostor syndrome runs amok in this field, and I am no exception. It felt almost unreal hearing some pretty glowing feedback after my first monthly check in. This led me to have a conversation with another engineer friend at a bigger company to ask about his experience. Funnily enough, he had a similar experience of getting a glowing review and really exceeding expectations. The difference for him was that he was not the only junior hire being at a bigger company and all. In his words, the low expectations are warranted from his observations.
Being thrown into a large codebase at any level is difficult and generally comes with a significant ramp up time. We can use low expectations to our advantage. Juniors are not expected to immediately start contributing to the codebase, we should take our time to learn as much as we can so that we can get to a point where we can make meaningful contributions as fast as possible. As opposed to trying to jump straight into a codebase and breaking things in an attempt to impress.
P.S. I am not trying to show off in any way. Impostor syndrome had me expect the worst during my first feedback session and I was just extremely grateful that I was getting consistent feedback at all. Additionally, it took me nearly two years after graduating college before I was even able to get paid to code full time.
Conclusion
This post already feels too long so I'm gonna stop here. This is my first post I've ever made so I'm open to some feedback or even suggestions on what to write about next.
Top comments (0)