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?
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
If I have Doc Brown's DeLorean, this is what I would advise my younger self
import this. Learn it by heart, then read no. 3 (above) againThere's a lot more, but these are my big ones
This comment needs a "share" button.
Dude, make a post out of this!
Here it is
If I knew then what I know now
Ted Hagos ・ Oct 5 '18 ・ 1 min read
Dude thanks for this! I'll be sharing it with some buddies.
Glad you liked it
I'll get right on it. Thanks
thanks @Ted_Hagos , i just started out as a junior dev
needs a PR.
So there's the tongue-in-cheek (ish) advise. Levity aside, let's look at another angle of the question. How does one get out or graduate from being a junior to something else; a senior, I suppose. This is an age-old question and a lot of brilliant minds tried to answer this (I'm pretty sure, a lot more brilliant minds in the future will still try to answer it), this is my favorite so far Programmer Competency Matrix.
Some of the item on the matrix might be abstract but some can get hairy detailed. I don't agree with all of it, but (at least) where I work(ed), there seems to be a general agreement on it. Take it with a grain of salt; remember, you found it on the internet
Please Sir be my mentor.
I'd love to, but I'm terrible mentor. Thanks though
Ok sir,though u don't sound like u will be a terrible mentor, but i respect your decision.
Okay Sir, though you don't sound like one who would make a terrible mentor, but I respect your decision.
This is probably the best advice I've ever gotten... ever. Thanks!
Please post repeated architecture and production information,thank you
Can you explain the point 3. I thought using design pattern is a good code practice.
He's basically saying "fit the solution to the problem, and don't over-engineer". Not everything needs a design pattern, so sometimes just keep it simple, avoid abstraction layers if possible, and don't optimise prematurely.
Design patterns are names for common solutions to common problems and therefore often just a label to shorten a discussion. Do not apply a pattern for the pattern's sake, but apply the right pattern to fit a given problem.
People should respect you. It's your right to push back against disrespectful interactions. If it's waved away with "oh, [person] is just like that," know that a) that is bullshit and b) both the person being disrespectful AND the one dismissing it are wrong.
You can become a great developer EVEN if you spend your nights & weekends doing other things. Be focused, make those work hours count, and then leave your office and spend your free time out in the wider world.
Resist tribalism in all forms.
a) Your role as a software engineer isn't more or less important to the company than other roles.
b) Your place on the stack isn't more or less prestigious than other places.
c) The technology you use has its ideal use cases - and so do all the alternatives.
Anyone who justifies something by saying it's "an industry best practice" actually has NO IDEA why they're doing it. Push (gently, respectfully) to see if they can articulate the actual positive outcome they expect.
a) same goes for "idiomatic," "more elegant," and "cleaner"
Do not read Robert Martin's books, unless you're working at a large, old company - and in that case, view them as anthropological studies that will help you survive in an alien environment.
More seriously - they're written for a previous generation, and while they might help you understand the current crop of 'senior' developers better, their techniques and attitudes are out of date and won't be useful to you moving forward. You're in a new world! You have the chance to make a real impact with your communication and technical skills. Go out & do it your way.
It's too bad I can only click the ❤ once
Could not agree more
Totally agree with this. I really had my hair on fire for the first few months I got a job, all because I believed I needed to be programming all day AND night. I only realized that could not be the answer when I found myself burnt out from programming in an actual job setting working with actual people. Spending 6 - 8 hours doing something was already plenty of practice. Taking care of myself was still required, and when I did so I became a better engineer (and better everything).
I’ve followed you for some time on twitter and most of what u say ressonate with me.
But this last point is plain wrong.
It disapoints me.
It makes me sad that u give such bad advice to new developers just because you have a grudge on UncleBob.
You should do some introspection and try to improve yourself as a person.
The fist 4 points apply to any employee in just about any job. Pretty much common sense. The 5th point is an unfortunate opinion. If the concepts in the Clean Code series were taught in college, we would an entirely different software landscape and the entire industry would be much more productive and less of a cause for stress. Thus allowing you more time to do what you love.
Yes, "you're in a new world! Go out & do it your way!" Ignore best practices! Feel empowered and special, ignorantly making the same mistakes that created mountains of awful legacy code left by the last generation of coders. Later, you can enjoy your "participant" trophy while professionals try to clean up the inscrutable, unmanageable, buggy hacks you've left behind!
I've heard Robert Martin books recommended over and over again, so really appreciate this thought!
Uncle Bob is politically conservative. Sarah finds him offensive, so she's added an attack against him to the end of her otherwise excellent advice.
Sarah should heed her own advice about tribalism.
Yeah, the difference between Clean Code and this advice column is time and evidence. There's evidence that the concepts taught in clean code work well and there's been plenty of time and happy developers to see it. Other than a pat on the back and a blackballing of Bob, I doubt there will be little useful substance from this piece in more than a few months of a young developer's life...stuff that they already didn't know or outgrow. It's common sense. What isn't common sense how to organize and test code at every level. It's one of the most empathetic things you can learn for your team and the one thing no one knows how to do out of school. I've seen devs drowning in complexity and domain with no way to organize or think about it. Then the framework abuse happens cause they don't know the concepts behind what makes the framework work. This is just advocating the kind of blind solipsism it claims to reject. Talk about tribalism.
All amazing advice Sarah!
Thank you for a great answer.
Seems most others answer the wrong question, either "how can a junior developer get to where I am?" (which was where my thinking went at first and why I felt uncomfortable giving an answer) or "what would I like my co-workers to be like?"
I would only like to add regarding point 1 that you also have a right to expect an environment where you are comfortable to speak and if that isn't the case it's never your fault. Any place where they think this happens automatically just because "we're all good people" is probably wrong in this, it needs to be actively encouraged.
So I guess the best advice I can give to juniors is that if there is something you want to change then "change your workplace or change your workplace." (don't remember who I'm quoting/paraphrasing)
Why do you think that Robert Martin’ books are out of date ?
I don't think they're entirely out of date for all developers, but I agree with Sarah's assessment for juniors. I specifically instruct juniors not to bother with that material early on in their career, but highly recommend it to folks who are a little further along—as great reference material, with some parts worth ignoring.
It's not that the advice and techniques are all out of date, but for juniors it could be hard to separate the dated from non-dated. It makes sense that an older book which covers a lot of ground would not stand up entirely over time.
I'm not speaking for Sarah's reasoning, but this is my answer for your question!
So it's okay for junior devs to write bad code early in their careers?! What a bizarre attitude
It's okay for everyone to write bad code sometimes. Not everything has to be perfectly structured and totally optimised. 'Tactical' can be good sometimes, and technical debt isn't always evil - as long as you aren't blind to it and have a plan to get rid of it or pay down the debt. Pragmatism is a key element of remaining commercial.
I could not agree more with point 5. Those books are a relic and most of the stuff in there has nothing to do with how software is actually built in the world (thankfully).
Would you care to post a sample of your code? I assume it is miserable. Because your attitude is very odd
I have programmed in a bunch of professional contexts and never had a complaint. All without that miserable character.
Which 'stuff' in those books do you disagree with? Is it the well structured code with sensible class, function and variable names and decent sized functioned, or the good OO practice and patterns or the properly tested code?
The comment about not reading Uncle Bob's books is pure prejudice. Except if it is some kind of joke which I don't get.
Talk about hypocrisy: tribalism and disrespect steeped in ideology are the norm of most interactions one reads from you.
I would give just one advice to all programmers in start of their career. Please spare sometime and read Robert C.Martin books on clean code. Namely
Clean Code and
The Clean Coder
It changes perspective of how one reads and writes code for better.
I taught myself to program on the job to automate a lot of repetitive tasks and eventually built a rather complex web app. One of the things I look back on now that I have been doing this for a number of years is my decision to look up and curate a list of best practices. I followed that as closely as possible and I think that was a life saver. I think any developer of any level can benefit by taking the extra effort to follow a best practice guideline. Just remember that they are in fact guidelines and that sometimes there are better ways to do things in a specific scenario, but that will come with experience.
can you maybe share your curated list of best practises?
I don't have my original list from 3~4 years, a job, and a move across the country ago but here is the gist:
Now not all of these may apply to you, such as Symfony, but I think for the most part these are universal.
I may be a little short on experience to give my advice here, I'm not exactly a senior but here's my two cents worth from what I've picked up from my own experience :)
If you have what you think is a good idea about how to approach a problem, voice it to your team! If it is a genuinely good idea, then it may be accepted and you can take the credit, and it will really boost your confidence! If it's not such a good idea, that's okay! More often than not, the more senior members of your team will explain to you why it's not such a good idea and possibly even give you pointers on what is, and then you've learned something - making you a better developer in the process.
Don't be afraid to ask questions! If you're stuck on a problem for more than an hour or so and you can't think of a way around it after searching for your it on your own, ask a team member regardless of how silly you might think it is! Chances are that it isn't at all that silly, and your team will be happy to help you in any way they can. After all, it's not only juniors that need to ask questions, senior developers aren't necessarily omniscient beings (although some do seem to be!)
Don't abuse or rely on this though, try searching/reading first - figuring stuff out on your own is a much more valuable experience than just getting an answer from somebody else!
Approach learning from an "Understand, don't imitate" perspective. Given the wealth of advice and examples available, it's so easy to find a solution that matches your exact scenario and just use that solution, rather than understand it. Learn how, and more importantly why, that solution works and apply that why to your scenario, even if it is the same.
Not getting your pull request through code review first time is okay. Everybody has their own approaches to problems, and a comment on your code review saying "X could be improved by Y because Z" doesn't necessarily mean you're not a good enough developer for only thinking of X, rather than Y. It's usually more a case of your haven't encountered a scenario that leads you to see the reasoning Z that causes you to use Y over X yet.
That's all I've got for now, hope it helps someone! :)
PS: Don’t work yourself to exhaustion trying to play catch up with the other developers, go at your own pace! Future you, your friends and your family will thank you for it! Coffee and vitamin supplements might be good for a temporary focus boost, but nothing compared to rest, socialising, exercise and hobbies!
Be open to change and don't let your job dictate what you are able to learn.
By "be open to change" I mean don't tie yourself to a specific technology, language, framework, whatever. Over the course of your career, you will end up changing course and I've found that those who are adaptable and open to learning new technologies are generally the most successful long term.
By "don't let your job dictate what you are able to learn" I mean, follow your passions regardless of what your job requires. Never say, "I want to learn X, but my job doesn't care about it." If you want to learn something, find a way to learn it, regardless of your job. It takes commitment and effort, but it pays off in the long run and keeps you from feeling constrained.
Finally, despite what I say in the paragraph above, do not believe anyone who tells you that you need to spend all your free time coding or beefing up your GitHub profile. Be a well rounded person, with interests outside of tech and code. The people and places that don't appreciate that should be avoided.
"First you search, then you ask". Learning things by yourself is much more valuable than sinply having somebody tell you how it's done, and even if you don't figure it out, you'll know better what it is you're struggling with. Eventually, if you're not figuring it out, don't be afraid to ask a senior developer, but prepare for the inevitable question, "what have you tried already?"
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.
Learn the basic concept of javascript first instead of learning frameworks like angular or react
I'd generalize this to all languages and frameworks. +1 though.
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.
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.
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.
Some overtime or off-hours stuff is more or less de rigueur in this industry, but expectations should be clear up front and the company you work for should respect your time. Never work for free.
Think about the impact your work will have and whether you'd be happy to sign your name to it. You can't eat standards but it's good to have them.
Hierarchies are efficient but can be working efficiently at cross purposes with you. The flipside is that they're brittle; sometimes it's easier to ask forgiveness than permission. The trick is in anticipating and managing the risks and consequences involved.
If you have to do the same thing more than twice, consider automating it.
Consistent, highly available, partition tolerant: pick two, depending on requirements. Cheap, reliable, fast: pick two, depending on requirements. Clever or maintainable: pick one, and there's a correct answer.
Reporting a problem you've discovered is good, thorough analyses are better, proposing a solution is best. It doesn't have to be right, it just has to start the discussion.
Everything everyone has ever written about "agile" boils down to "more and shorter feedback loops". It's a good idea but shouldn't be over-complicated. Adapt processes to fit people: people may be the squishy part of the equation but we aren't liquids and don't take the shape of our container.
Pay attention and put some effort into how you communicate, especially in contexts where you can't rely on facial expressions and body language to add nuance. It's easy to make assumptions about what other people know and feel and easy to come off differently than you intended, and it's rarely for the better.
Every Turing-complete programming language is a different method of expressing the same fundamental formulations and processes, and understanding the general principles underlying them is more important than the ability to navigate any one system (& the former is arguably a prerequisite for doing the latter well). The specific language you're working in is essentially a matter of taste; the concepts always map across one way or another.
Crap code in prod makes you more money than elegant code you haven't finished yet, but by the same token there's nothing so permanent as a temporary kludge.
For all the stereotypes of hyper-rationality, software people really, really love fads and often overlook limitations or issues that make their pet idea a bad fit for what they're trying to do. The current overuse of blockchain only proves we didn't learn the real lessons from NoSQL or microservices.
Object/relational mappers are more trouble than they're worth.
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.
Always accept the suggestions of seniors!
And don't give up the first "shity tasks".
+Always understand the background of the problems: if it is not clear what and why are you doing use google and understand the issue in full details!
The background story:
As I started as a junior, fresh from the university I started at a big company. I had a lot of great ideas about how to solve the different issues, but most of the cases the senior developers on the team just told me that it's not really a good idea, sometimes with a reason, sometimes without that. Later on with time I understood that these were really not so great ideas as I thought.
So in my first year I got always tasks which were extra boring for me and I thought they are too easy. So I was a bit demotivated. In the first time I had still a lot of mistakes in these easy tasks. So first I needed to reach the level that I could implement these easy tasks fast and without bugs, after that I got more and more complex tasks. Every time I could successfully fix something I got something more difficult as next task and it worked well. After one year I was working on really interesting and challenging tasks and I was able to achieve them.
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 :))
In short: do as many different things as you can.
Now a slightly longer explanation.
Of course I don't mean to just rush from one thing to the other, never quite learning anything. Of course take your time to familiarise yourself with the tools you're working with, the environment, and so on. But if you're feeling you're already up to speed and comfortable, and an opportunity arises to do something in a new language (for example), and it's okay that you haven't got any experience in it yet, go for it. (Never lie about your experience, leave that sort of stuff to management consultants. :))
What I also don't mean is to never stop doing this. This kind of strategy is fine when you're starting out, and some people stay like that forever, but most eventually will settle for one thing and go very deep in it. But even they will benefit from knowledge of other languages, paradigms or indeed roles.
And of course the usual caveat: this isn't a recipe for success (indeed it's not about success at all, more like feeling your life is worthwhile), just a heuristic that is based on a tiny sample I've personally witnessed, and for added bias, I fall into that sample too.
Your worst days, when you practically feel like quitting, are often the days you learn the most. Sometimes you don't even realize how much you've learned, and you feel like you just wasted your time, but those days can be extremely helpful.
Had this thought top of mind after reading @jmdembe 's tweet a few minutes ago:
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*)
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.
Be ready to adapt. Not one programming job is the same, not even within the same company, not even within the same team!
Find out what works and push in that direction. People will recognize your efforts, and if it aligns with the context, they will rally to you.
Admit when you failed and give credit to others for every little thing.
Stay out of the x language, y framework is the best mentality.
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!
Remove the junior part.
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.
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.
Here's some of my advice to junior developers that join us: be yourself. Some of the best code out there is not spoken for. Some of the smartest hacks were not discovered by usual heroes. Keep personal happiness over everything else. The most performant code is one that hasn't been written yet. No code is no bug. Read a lot. Write a lot. Code a lot.
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.
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.
Patience
One and only one option for self-learner
Learn how todo unit tests and functional tests, they will save you.