We were all juniors at some time, and in the spirit of sharing here: what's some good advice for junior developers?
What things would you like to tell yourself when you were a junior?
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (75)
Patience
It's really hard to give advice to anyone let alone someone who is trying to work in an environment as fast pace as development, but here are some general things I talk about to people around me and stuff that awesome people have suggested to me.
1°) don't be arrogant, thinking you never make bugs and try to hide it
2°) don't be lazy, try to find and fix these bugs, dont count on QAs to do this job for you, that's unprofessional
3°) don't be impatient, learn as much as you can before thinking you are a senior (yeah read Uncle Bob ;) )
4°) don't be coder only, try to really understand the need of business and not just do the minimum of their requirement especially when requirements are fuzzy. Requirements are the hard part actually not the coding part.
5°) do have empathy for business people, don't think they're stupid just because they cannot understand your technical jargons, they also have a lot of complexities in their field you wouldn't even understand either.
6°) life is not fair, your career also depends on how you sell yourself to Tech Leads / Managers - but don't oversell or you'll get into imposture syndrome which will lead you to always cheat with people and yourself.
There are a lot more but that's first things I have in mind.
Find reputable online people that you trust and learn from them. When co-workers teach you, compare what they tell you with what you've learned. Trust, but verify.
Why? Because depending on where you work, many people who try to tell you how to work don't know what they're talking about. Or they know some things really well but not others. Sadly, the less they know, the more likely they are to try to teach you. That puts you in a difficult position, one where you have to evaluate the knowledge of people with more experience than you.
(This could be unnecessarily negative. Maybe I just had really bad experiences.)
The point isn't that you should correct everyone or try to be smarter than them. Rather, you need to defend yourself against learning wrong things. If someone tells you things that you learn are wrong, politely question them. It could be a misunderstanding, or perhaps you didn't understand what you read. If it's black-and-white and they don't get it, stop questioning them out loud but question everything silently.
Hopefully you'll find people who have spent some time on the right track. In my first few years I had the chance to learn from several and missed it each time because no one told me what I'm telling you. If you find such people, learn as much as you can from them.
Don't act like a junior, act like a senior, kinda the "do" version of "Dress for the job you want, not the job you have". Don't just do your job and stop there, find out more about the product, the company, the workflow, and implement changes to make things work better.
Personal example: I was hired to run environmental chambers and DC power supplies for a company that was testing computer-like equipment for reliability. Essentially, crank the temperature up and down and vary the voltage till the product fails, then get the engineers to fix the root cause, then retest. This means product won't fail at customer sites...
This is a very tedious, boring, time-consuming, and error prone process. Crank up the temperature, wait an hour for the machine to stabilize, turn the voltage down by one percent at a time till the product fails, reboot at nominal voltage, turn it up one percent at a time till it fails, reboot at nominal, pick a new temperature, rinse, lather, repeat. Ripe for automation! But programming wasn't in my job description. By the time I was done we had a half a dozen chambers, multiple sets of DC power supplies, video sources and recorders, and everything was running 24x7 on a scripting 'language' I developed for putting things through their paces. Wrote and implemented it all in those one-hour temperature soak periods, plus nights and weekends, plus time I freed up from having to sit and watch the chambers.
Big win, and my Grand Unified Program made a big difference in our department's productivity and throughput.
Every job is going to be different, but don't just learn what you need to do your job, learn everything about the company and the industry and the technology, and use that knowledge to make things better.
Don't start by asking permission, and always ask forgiveness. 8*)
Don’t be afraid of working with older, less fashionable languages or frameworks. They were fashionable at some point for a reason.
Even ignore you’re not using the latest and greatest tech you have a tremendous amount to learn from soft skills to version control to team work. Learn everything you can and never stop being curious.
I've read through all the otherwise wonderful advice on this thread, and there seems to be one area that we've all overlooked, and which in hindsight I wish I started thinking about earlier.
Ethics.
We don't like to think about our profession as one that has moral responsibility for the things that we create. Morality is a squishy concept, ever shifting and difficult to pin down, but with software playing an ever bigger part in our society, we simply can't avoid that discussion.
I'm not going to pontificate about what's right and what isn't, not least of all because I don't know either, but I'm sure it's important, and we must start thinking about it as early in our careers as possible.
Don't get overwhelmed by things that you don't know.
Focus on one problem at a time instead of trying to figure out solutions for many different problems.
Take a break.
Focus on your growth and don't compare yourself to others. You should be inspired by other people's accomplishments.
Don't worry about the framework of the day or library of the year. Focus on the basics.
Take everything with a grain of salt. Do your own research and make an educated decision.
Don't just make data-driven decisions. Let the data guide you.
Embrace change. Nothing is permanent.
Employers don't hand down a big raise, bonus, or promotion. You control your career, so you need to ask for it.
Side projects will help you stay on the cutting-edge.
Pick a language, framework, and ecosystem and stick to it as long as you can. However, be prepared to learn something new when the time comes.
Interviews are unfair. Don't let them demotivate you.
Don't be afraid of engineers senior to you and those who have been in the industry for long. They will most likely be opinionated and they're not always right. At the same time, you can learn a lot from them and they can learn from you.
Two things:
First, understand that the code you write is going to have real impact on real people. Algorithms are not unbiased by default because a person had to write them. Your preconceptions and biases will leak into your algorithms unless you actively defend against them.
Second, admit your mistakes and learn from them. Most of us have a story about deleting that one file that brings down a system at critical time of year. If we ever meet over a beer, I’ll tell you about crashing our learning management system during final exams. When (not if) this happens, take responsibility for it. It will be uncomfortable, and you may fear for your job, but I promise, if you are working for a quality organization, your honesty will be appreciated by your managers, but more importantly, by your colleagues. You can only throw coworkers under the bus so many times before they return the favor.
You will find many similar answers for THE junior (general stuff), but the tricky part is to give advice for A specific person. Each individual has its own ups and downs, lacks and skills.
So think of your career, what are your aspirations, what do you like, what are your opportunities (probably are limited by geographical or other working preferences), in what areas do you lack and get more specific feedback to reach your next career step.
I guess this counts as an advice as well :))
There isn't a single Way to the Top, because The Top looks different for different people. For more on that, I'd recommend:
So try to develop all-around competency, but figure out what draws you. Maybe it's writing awesome application code. Maybe it's visual aesthetics for web and mobile apps. Maybe it's Ops. Maybe it's algorithms and/or machine learning. Maybe it's dealing with people and being a leader. (Industry secret: Many managers, even with programming backgrounds, are less skilled programmers than most of their subordinates, and that's not actually a problem!)
You need a little bit of everything (though there are exceptions, e.g. you can probably skip machine learning if you're focused on line-of-business web apps, and there are probably almost no cases where knowledge of both writing mobile apps and hardware hacking is necessary), so look for opportunities to round out your experience. Over time, you will hopefully find a specialization where you can really shine. It's kind of like college in the US (i.e. not European) model - take some general courses and then declare a major. It's OK not to have a major yet when you're new. It's also totally OK to like lots of things as you move along, and go back and forth flexing different muscles as you progress. (As an example, see Charity Majors' essay on bouncing between engineering and management positions.)
Finally, if anyone RTFMs you or references you to Eric S. Raymond's essay on how to ask smart questions, RUN and don't look back. As a junior, you need an environment where you feel safe asking questions, knowing you'll be respected for doing so. That difference can shave years off the time it takes to graduate from junior to mid.
Oh, and when you do move into a more senior role, remember how hard it is to be junior, and find ways to mentor/pair/be available/encourage questions DURING work hours.
P.S. If you're interested in public speaking, you don't need to be an industry expert. Most speakers aren't, they just (ideally) know how to research and craft data into a good story! You really can become a prolific meetup/conference speaker much earlier in your career than you'd think!
One and only one option for self-learner
I am currently working as an intern in a game development company. The reality of working in actual company tells me that the stuff I have spent years and years studying in Uni or college might not be applicable in my work.
Stepping into the office feels like literally stepping into an alien spaceship. The task I was assigned was too big and I wasn't able to handle it until had panic attack.
However, I do acknowledge my lack of "productivity" mostly stems from Impostor Syndrome and me overcomparing myself with my fellow devs.
I would say everyone has their own pace. Do not rush yourself, you will get to where you want.
There are tons of things to do when you are a junior and people here here are suggesting a lot of great things, but if there is a single advise that I would give to a junior it would be:
Read code. See how people have solve a problem and how the solution was formed in order to be Solid and testable. Then when you write code try to implement a thing or two be yourself.
Bruno Souza (Java Champion) has given me this advice and I keep doing it ever since.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.