learn how a relational database works (this is always useful)
learn how HTTP works in general
learn how to debug code in one language (it's pretty much the same in others, you can recycle most of the knowledge)
be familiar with the command line
know how to find code (either using your IDE or grep on the command line)
knowing the basics of regular expressions will get you far (also to find code in the previous point)
know how to find solutions using a search engine
know how to operate git (I would say any source control but git is the de facto standard so you might as well start with that)
ask questions, especially if you think they're not worth being asked
learn how timezones work (not kidding, lots of devs are still fuzzy on these)
learn how unicode and utf-8 work (same reason for timezones)
have a general idea of how caching (CPU, in memory, disk, HTTP) works as a concept
notice that other than git I didn't specify any particular tool, this is because it's stuff you will bump into no matter which languages or tools you'll end up using.
I am not sure about the "without IDE". How would that help you? The hard part is to learn how to reason, and think like a programmer. Not getting help finding errors in your syntax, or suggestions on functions and features just makes you struggle :)
An IDE indeed helps you a lot and reduces the struggle... and that's exactly why you should try to be able to code without it. Especially since you can't always have/choose an IDE.
Using an IDE as help is great, depending on it to produce acceptable code is not.
I've seen too many junior devs being completely lost when their favorite IDE was taken away.
The problem is that no junior will ever write quality code, and neither should you expect them to. The most important thing for a junior is for them to easily get up to speed, and realize that "Wow! I can actually do something with this". Trying to focus on quality early, and you'll just struggle and lose motivation. How do a junior even know what quality means?
The will to write quality code grows from professional pride, and that comes later when you understand what you're doing and can make good decisions from experience. That is my view of it all.
Well then "quality" might not have been the right word. I mean code that works. IDEs will do a lot for you, including fixing your mistakes, which often means you won't learn from them.
I do agree with what you say about motivation though and I feel like I should clarify my thought: I'm not saying juniors should not use IDEs, I'm saying they should avoid using only that and sometimes go back to the basics so they can fix some mistakes by themselves and learn whats happening in the background (building process is also something IDEs hide a lot).
I just feel like learning to code only using IDEs is like learning to drive on an automatic transmission... but then again, it's the norm in some countries, so let's agree to disagree if you think that's ok 😁
It isn't about the syntax at all, it's quite often about the build process and other things that IDEs like to hide away from you, making the whole dev cycle a lot smoother.
But this will come back to bite you in the backside when it suddenly doesn't work as you expected it to, and you've got no idea what is supposed to happen under the hood.
Does acquiring the knowledge to solve these situations worth the extra hassle? I think it definitely does, all IDEs are fallible.
Do I think we should shove it down junior devs' throats then?
No, not at all. Particularly in the very early days, the enjoyment of creating something, anything, is a lot more important for me. But you do need to come back to it and learn the underlying mechanics with time, certainly by the time you become a senior dev, I'd expect you to know how to build something with just the basic tools.
Most people's natural curiosity will take them there anyway.
I know you asked for tools and techs, but I'd put self care and how not to burn out. Nobody actually teaches you this, and the assumption that you'll just push through/work like a demon/code till your eyeballs fall out is still way too present in the industry. Don't lose your mind, I've done it once or twice and it'll hold your progress back.
In terms of tech - how to isolate root causes. Extracting the smallest piece of code that reproduces the issue you're trying to solve will save you tons of time. Unit testing will definitely get you most of the way there.
I'd also add that it's way less about the tech stack of the day than the principles that lie beneath them. SOLID/DRY principles, MV*, abstraction, source control skills, debugging, caching and being able to decompose the problem will serve you longer than any particular stack will. For example, because I'd encountered MV* stacks in other languages, I was able to pick up Laravel in next to no time this year - got an app up and running in hours. I fully expect that when I pick up my next unknown framework (probably some iOS dev) it'll be the same, because I understand the patterns and principles at play.
I know you asked for tools and techs, but I'd put self care and how not to burn out. Nobody actually teaches you this, and the assumption that you'll just push through/work like a demon/code till your eyeballs fall out is still way too present in the industry. Don't lose your mind, I've done it once or twice and it'll hold your progress back.
Well said! I burned out once too and it isn't pretty.
Trying to add a few bullet points that other's haven't already mentioned...
Learn your build tool of choice well. You'll be amazed at how much time you save when you know how to automate your repetitive build tasks. If any given build process takes more than 1 shell command, you're doing it wrong.
Be able to read and understand code written in a language you've never used before. Many times when solving a problem you'll only find snippets in other languages, but you've got to learn how to translate that to your own when no examples exist in your preferred language.
Conventions are great and considerably cut down on development time, but make sure you know what's going on under the hood as well. Don't just blindly accept the convention as a black-box, because that's the surest way to introduce subtle bugs that are difficult to squash.
Learn how to quickly adapt to change. Your career will find you constantly trying out new frameworks, new languages, new development environments, new project teams, new managers, new development and project-tracking styles.... make sure you are able to keep up and get productive quickly no matter your new situation.
I consider my self a Junior Developer at the moment. I have been working for about two years now in the Microsoft Stack. A couple tools or technologies that are key are:
GIT
Any good text/code editor. My flavor: Visual Studio Code
Greatest tool you can have as a Junior developer is asking questions.
Hi Julia!
in no particular order:
notice that other than git I didn't specify any particular tool, this is because it's stuff you will bump into no matter which languages or tools you'll end up using.
Worthy of a boost:
12 Things Every Junior Developer Should Learn
Ben Halpern
Ahah! Thanks Ben!
Besides basic code logic (loops, conditionals, etc...) I'd say every junior developer should learn at the very least:
Oh, and also: learn to RTFM 😉
I am not sure about the "without IDE". How would that help you? The hard part is to learn how to reason, and think like a programmer. Not getting help finding errors in your syntax, or suggestions on functions and features just makes you struggle :)
An IDE indeed helps you a lot and reduces the struggle... and that's exactly why you should try to be able to code without it. Especially since you can't always have/choose an IDE.
Using an IDE as help is great, depending on it to produce acceptable code is not.
I've seen too many junior devs being completely lost when their favorite IDE was taken away.
That just sounds like gatekeeping elitism to me.
How so? I'm just saying being able to produce quality code without your favorite IDE is a good skill to have.
The problem is that no junior will ever write quality code, and neither should you expect them to. The most important thing for a junior is for them to easily get up to speed, and realize that "Wow! I can actually do something with this". Trying to focus on quality early, and you'll just struggle and lose motivation. How do a junior even know what quality means?
The will to write quality code grows from professional pride, and that comes later when you understand what you're doing and can make good decisions from experience. That is my view of it all.
Well then "quality" might not have been the right word. I mean code that works. IDEs will do a lot for you, including fixing your mistakes, which often means you won't learn from them.
I do agree with what you say about motivation though and I feel like I should clarify my thought: I'm not saying juniors should not use IDEs, I'm saying they should avoid using only that and sometimes go back to the basics so they can fix some mistakes by themselves and learn whats happening in the background (building process is also something IDEs hide a lot).
I just feel like learning to code only using IDEs is like learning to drive on an automatic transmission... but then again, it's the norm in some countries, so let's agree to disagree if you think that's ok 😁
It isn't about the syntax at all, it's quite often about the build process and other things that IDEs like to hide away from you, making the whole dev cycle a lot smoother.
But this will come back to bite you in the backside when it suddenly doesn't work as you expected it to, and you've got no idea what is supposed to happen under the hood.
Does acquiring the knowledge to solve these situations worth the extra hassle? I think it definitely does, all IDEs are fallible.
Do I think we should shove it down junior devs' throats then?
No, not at all. Particularly in the very early days, the enjoyment of creating something, anything, is a lot more important for me. But you do need to come back to it and learn the underlying mechanics with time, certainly by the time you become a senior dev, I'd expect you to know how to build something with just the basic tools.
Most people's natural curiosity will take them there anyway.
Hi @julia ,
Here I am listing all the tools or technologies which Junior developers should learn:
Through below-given infographics get complete details:
I know you asked for tools and techs, but I'd put self care and how not to burn out. Nobody actually teaches you this, and the assumption that you'll just push through/work like a demon/code till your eyeballs fall out is still way too present in the industry. Don't lose your mind, I've done it once or twice and it'll hold your progress back.
In terms of tech - how to isolate root causes. Extracting the smallest piece of code that reproduces the issue you're trying to solve will save you tons of time. Unit testing will definitely get you most of the way there.
@rhymes hits paydirt below too.
I'd also add that it's way less about the tech stack of the day than the principles that lie beneath them. SOLID/DRY principles, MV*, abstraction, source control skills, debugging, caching and being able to decompose the problem will serve you longer than any particular stack will. For example, because I'd encountered MV* stacks in other languages, I was able to pick up Laravel in next to no time this year - got an app up and running in hours. I fully expect that when I pick up my next unknown framework (probably some iOS dev) it'll be the same, because I understand the patterns and principles at play.
Well said! I burned out once too and it isn't pretty.
Yeah it totally sucks. I just got inspired to write a post about it. There are things we can do to prevent it and work with it!
Trying to add a few bullet points that other's haven't already mentioned...
I consider my self a Junior Developer at the moment. I have been working for about two years now in the Microsoft Stack. A couple tools or technologies that are key are:
Bash useful commands such as less, tail -f, tee, grep, sed, jq (should work for every developer related job)
How to use a debugger
How to use your EDI
How to use online VM (for instance Google Compute Engine or Amazon WS)
The rest depends on your specialization
Source control (git).
This is the #1 tip I can give any developer. It gives you a lot more freedom to experiment.
If you want to be a web developer: