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
Oldest comments (75)
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:
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.
"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?"
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 is probably the best advice I've ever gotten... ever. Thanks!
This comment needs a "share" button.
Dude, make a post out of this!
I'll get right on it. Thanks
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
needs a PR.
thanks @Ted_Hagos , i just started out as a junior dev
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.
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.
Please post repeated architecture and production information,thank you
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.
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.
Stay out of the x language, y framework is the best mentality.
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.
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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.