For further actions, you may consider blocking this person and/or reporting abuse
Read next
How do you take the first steps in a daunting and complicated software project?
Ben Halpern -
The story behind John Doe
Muhammad Essa -
Why Cookie-Less is the Future for Tracking Analytics in Europe (and the World)
Antonio | CEO at Litlyx.com -
The hidden cost of code reviews
Marco Patiño López -
Top comments (20)
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: