In a previous article, we looked at the various stages that I feel are helpful to use as a general template or framework when thinking about how a typical developer may transition throughout his/her career.
The first transition is moving from being a Coder to a Junior Developer.
Here, I'll offer some advice for those who might be facing this transition.
Also, if you personally are "beyond" this stage in your career, it still may be helpful to go over since many of these tips are still helpful in general.
Having this knowledge is also helpful when you mentor or just want to help other devs who are in this situation π.
Coder
A Coder is basically a hobbyist. They aren't paid professionals but enjoy coding in their free-time.
Typically, they work alone on their projects.
A Coder might have some of the following traits:
- May know a couple programming languages well
- Might have an in-depth knowledge of syntax
- Is able to solve problems that arise in smaller projects
Junior Developer
This transition is marked when someone enters the field in their first paid position.
Something developers will learn quickly is that being a developer isn't all about "pumping out code".
You will be expected to take business requirements and turn them into applications and tools that solve real-world problems.
Here are various tips and advice that I have for those facing this transition:
You're On A Team Now!
Yep. That's right. People. Lots of people.
This adds a whole new dimension!
Here are some pointers around being a great team member:
Communicate Clearly
You need to be aware of what matters when you are in discussions.
For example, if you are expected to tell everyone what you are working on for the day - don't deep dive into the specifics of what you are doing.
Instead, briefly indicate what general task you are on and whether you need help:
"I'm going to fix a bug related to the main menu on our mobile app, then I'll keep working on the new feature X."
I've seen so many devs just jump right into the technical specifics of what they are working on. That's just a waste of everyone's time and energy!
Emotional Intelligence
We all have bad days.
Your teammates are people.
Treat them like they are people.
Try to encourage them when possible.
And if you do have problems, start by addressing issues one-on-one. But choose your battles wisely. If Fred is having a bad day, then it might just be best to let time take its course.
If an attitude, etc. is affecting the team as a whole or for an extended period, your managers are there to help you address issues too.
P.S. This article is originally from YourDevCareer.com where you can check out more articles and resources to help accelerate your career growth!
It's Too Big For My Tiny Head!
Now on to some more general areas of advice!
You will quickly find yourself working on codebases that aren't like the ones you had in school. You could fit those ones in your head.
In the real world, you will face massive codebases that are just not possible to fit in your head all-at-once π€―.
When I started as a junior developer I was expected to start working with a database that had over 700 tables and thousands of functions and stored procedures. As someone just starting out I was really overwhelmed!
You will be overwhelmed too.
We've all been there.
It just takes time.
My advice: Write everything down before you touch code!
Figure out a strategy on "paper" first.
Break the problem down into small steps. Write down each step.
Here are some things you might want to include:
- What database tables/columns will need to change?
- What code files will you need to change or investigate?
- Are there any known design patterns that address the core issue?
- Are there any unanswered questions or ambiguous requirements?
- etc.
Your peers will really appreciate your taking the time to break everything down.
If you do need help, they will be more-than-willing to help you.
It will just be easier for everyone involved - even seniors can't remember everything and fit it all in their heads! π€£
Keep An Achievements Library
Keep a journal or spreadsheet of every major task that you complete. If possible, include metrics that might be relevant.
For example:
"I improved the speed of a critical SQL query by over 200%"
"Completed feature X which lead to X number of new clients for the company over the next 6 months."
"Learned about the SQL APPLY operation and used it to migrate company X's data 50% faster than before."
This will be great for you to look back at privately to see what you've accomplished. We all get down sometimes and fall into seasons when it feels like we aren't doing much good.
But, it will also help when the time comes to re-do your resume. You'll have lots of ammunition!
Learn How To Research
Einstein is quoted as saying something to the effect of "Never memorize something that you can look up."
This is the software developer's mantra!
Even senior developers have to research things every single day!
My advice: Read. Read a lot.
Read things that are a little bit beyond your comfort zone and current understanding.
That will stretch you. Eventually, you should be able to read faster and even learn to skim material quickly.
This can make the difference between a mediocre developer and a super developer.
If you can quickly find the answer to something you don't know how to do, then you will be respected as someone who can answer other people's questions quickly.
You'll become someone who "levels-up" the team they are on.
Community
One of the things I personally regret not doing sooner is getting involved in the developer community.
This will help you find jobs, make new friends, find mentors, and make you feel like you a part of something bigger than just yourself and the company you happen to work for.
Figure out who the "best" developers are for your particular field and interests.
Follow them on Twitter and start reading and commenting on their blogs!
Other things you can eventually get into:
- Start contributing to open source projects (even just documentation!)
- Start an open source project
- Attend local user groups, meetups and conferences
Specialize
I already wrote about this in a previous post:
![jamesmh](https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F93505%2Fc8881a55-01b1-4504-a36c-24606b1bb3c6.png)
How To Stand-Out Among Your Peers As A Software Developer
James Hickey γ» Feb 20 '19
C'est Tout Fini!
Yes, that's French.
Let me know in the comments what you thought!
Do you have any other tips or advice for those starting out their journey as a software developer?
Keep In Touch
Don't forget to connect with me on twitter or LinkedIn!
Navigating Your Software Development Career Newsletter
An e-mail newsletter that will help you level-up in your career as a software developer! Ever wonder:
β What are the general stages of a software developer?
β How do I know which stage I'm at? How do I get to the next stage?
β What is a tech leader and how do I become one?
β Is there someone willing to walk with me and answer my questions?
Sound interesting? Join the community!
Top comments (16)
Perhaps an unpopular opinion, and I understand why people do this, but once you get your first developer job, drop the "junior." You're a developer, be confident! It might help some of the impostor syndrome!
I think it's important to understand that you have a lot to learn - years worth of learning!
But yes, as a tactical move, speaking and presenting yourself as a "developer" vs. "junior developer" can help in marketing yourself and even positioning yourself confidently π
I don't think anyone new to having a career in development goes in thinking they are expert, but keeping the "junior" mindset does seem like it could be a little self-defeating in wanting to grow and learn.
Really like the achievement list idea, I wish that had ocurred to me before. Right now I'm rewriting my resume to transition more into a development job and that would have certainly be useful. Great Article!
Thanks Robert!
Thank you for you paper , It was so useful , but how we know we are junior or not
for example in my CV ? I think I shouldn't call myself junior and let the company to assign whats my level , Do you think is it true?
That seems like a decent move - just call yourself a "software developer".
Thanks for the great post! I think it's important that we discuss these issues in a constructive, action oriented way, as you do here.
I particularly like your point that the codebases are different than the ones we used in school, whatever that education may be for you. I'm a strong believer in the importance of soft skills as key to success and happiness in development careers, something that is often not talked about in a formal education setting.
The article 7 hard truths about starting your career as a developer addresses some similar concerns and pieces of advice that you offer here.
i really like this article and the idea of an achievements journal. i think this is something that all developers and aspiring developers should read.
Not sure there's a "right" way. You might want to start with tutorials so you can get some basic understanding of what is possible.
You might learn better by watching videos?
The best, I think, is to just solve some real problem. Learn as you go!
I think this is generally great advice for any newbie -- I wish I was able to read something like this back in 2013 when I interned at a startup as a graphic designer. Great read! I really like the paper and a list idea, and keeping a private list of achievements too.
Thanks for the great post! As a self taught developer looking for my first job this was right on time.
Sweet! Good luck π
Love the achievements library idea. Every developer I've spoken with talks about how the learning feels soooo sloooow until you look back and see all the distance you've already covered.
Those achievements might help in your CV
Yes, it will def. give you a whole list of ammunition to work from π