I want to boost @rhymes wonderful response to the question What are the essential tools and technologies that every junior developer should learn?
Hi Julia!
in no particular order:
- 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.
Hope it helps someone.
Is there anything else you'd add to the list?
Top comments (20)
KISS before DRY.
K.I.S.S.
Brian Nipper ・ Sep 18 '18 ・ 1 min read
What Nursery Rhymes Teach Us About The DRY Principle
Jake Varness ・ May 15 '18 ・ 4 min read
3 Steps to DRY
Ryan Silva ・ Aug 30 '17 ・ 2 min read
The difference between a "junior" and an "intermediate" is how much direction they need to be given in order to be effective.
A junior needs to be shown the way, and only then can they make progress. They'll have a lot of questions about pretty much everything, but that's expected, as that's how you learn. Example: "If I'm using jQuery, how do I get the value of a field and send that to the server?"
An intermediate is someone who, given a general description of the problem, can make significant progress without a lot of intervention. They'll have questions that are more on a strategic level, not an implementation one. Example: "Should we use this plugin from jQuery UI to handle this date picker, or do you know of a better alternative?"
A senior is someone who, given a problem, works to understand it and can come up with a solution independently. They'll have questions, but they'll be to dig deeper into the problem and to better understand the true objectives. Example: "At some point the way we're using jQuery is going to create a lot of technical debt. Can we work towards using a proper framework like React or Angular?"
The biggest trap is being an "advanced beginner" where you're never really learning the fundamentals, you're just learning a lot of tricks and hacks that give you the illusion of learning things. That happens when you just do things without questioning why, and when faced with a new problem only apply techniques you've done before, no matter how ill-suited they might be, in the hope that one of them will magically provide a solution.
I'd say if you know all those things you're probably an intermediate, as juniors are, by definition, only dimly aware of those concerns. They don't know what they don't know, they're basically blind and lost. Intermediates are those that have come to know what they don't know, and know to ask for help when necessary.
I think another really useful skill is to learn how to QA/Test your code. Automated, manual, whatever. It's super useful and people will appreciate it.
I would add learn basic criptography.
And if you have spare time, learn how a computer and memory works (just because it's really cool). Doing something in C may help in this process
I see a lot of comments about OSI model and networking, while This seems helpful for reading through a call stack and picking out some errors easier. Where does this fit into something that would help a JR, are there more specific examples of where it helps or is it more general background helpful knowledge.
Genuinely curious, since I want to get better.
From my lived experience in Helpdesk and DevOps before I fully jumped into programming, having the OSI Model and troubleshooting as a background has dramatically improved my learning and retention of programming concepts.
On the model, understanding it allows you to abstract and understand where your code or portion of your program is operating, and if you have to think about things differently depending on how deep in the model you are. Some frameworks do a lot of the lower-level thinking for you (Laravel, React, Vue, etc), but understanding what is going on will save you headaches on bugs later.
Layers 1-4 are often going to be back-end development, wheras 5 on will usually fall underneath front-end development. The design choices you make for each level might look like (and if my examples are wrong, let me know and offer what you would think is a development use case at whichever level):
1) Physical:
Most everything has been solved at this level. These are the building blocks we don't usually have to play with to make things work. If you are working on things at this level, my understanding would indicate you are working on some sort of networking hardware or some other physical system to inform the data link (like signal processing and logic), but not to tell it where to go just yet.
2) Data Link:
At this level, this is you setting up the infrastructure and traffic-lights (or 4-way stops, or roundabouts, etc) as well as cameras to check for accidents (error checking/handling transport). At this level, you are dealing with packets and flow of them, so any of the work you're doing here is more often than not still backend development.
3) Network:
If the first two layers are the city level infrastructure, Layer 3 is the highway that connects the cities together. At this level, this is where you are dealing with more ip handling and routing, hosting (everyone has to have an address), and more. This level is the playground of most networking developers and is still very much a backend part of the stack. Not that you cannot make front-end decisions at this level, but most I have come across do not.
4) Transport:
Layer 4 deals with logistics and reliable transport. This is where you would be messing with sockets and multiplexing, and complex routing to carry larger loads of data. Again as with the previous layers, this is a back-end part of the stack, and unless you really like rolling your own solutions, there are so many frameworks and resources out there to achieve a good portion of this development work for you.
5) Session:
This layer is now where the front-end and back-end get a little muddy. At layer 5, you are starting to deal with a user of some kind, and measuring and reacting to their inputs/outputs accordingly. Online video is beholden to this layer for making sure that audio and video match. It's the equivalent of a warehouse or shipping center, where all of these separate objects are coming from different places, and need to be sent on to their destination as complete as possible. Javascript and XML would make sense to me at this level, as they are performing the sorting tasks, but there could be better examples. Mostly back-end, but ties to the front most of the time in my current experience.
6) Presentation:
This layer is where you are almost showing the user what the thing looks like, but it is still relaying and handling the logic that doesn't need to be seen by the end user. This is the storefront that the packages come to, or the mailroom/mailbox for your place of residence. You know that things show up there, but how it gets there is not front-of-mind. PHP and similar languages would fall into this layer for me, as they deal with the heavy lifting of whatever you do on the front.
7) Application:
This is where you get to do any fancy visual stuff. The protocols for this layer are still back-end heavy, but to me, this is where there is more overlap in the model for the work you would be doing here. Understanding what is happening on the backend is useful to know if your work on the front is feasible, or if it provides problems deeper than you realized. Knowing your stack is important to make sure that you are not missing things or opening yourself to future vulnerabilities. At this layer, you're dealing with UI/UX decisions, and the frameworks/languages/build tools that come with that.
And my favorite, and most overlooked layer
8) People (The space between chair and keyboard):
The human layer is the most fickle, and the one that will bring you the most pain. Programing at this level is more of a test of your communications skills, project management, and design ability. By 'design integrity', I mean that you can take an issue and abstract it into the business logic needed to solve for the issue at hand and NOT allow someone outside of the process to influence the design. Know your tools, their limits, and don't break your tools because someone who doesn't use them thinks that they are better equipped than you to wield them.
Hopefully this made sense and helps. If not, let me know how else I could improve on how I approach this :)
Awesome! Thanks so much for posting all the details here. This is great stuff, I actually have an IT background ass well, so it's nice to know I'm not alone, making that transition.
I think "ask questions, especially if you think they're not worth being asked" is worth expanding upon.
When I've had juniors, I've found that this should really be broken into two issues:
I've seen people who have languished for (imo) far too long before seeking out help, and we've had people who ask for help frequently, but it often takes a little digging to get to the root of their problem.
It would be great for some good links to be included along side these suggestions. I really like the post, but only 2 or 3 are easy to go out and take action on. Like Git, lots of videos books, etc. HTTP/S Is a good example of a challenge to learn IMO and therefore 2-3 good links would be greatly appreciated.
Regardless i super appreciate the time taken to write it and share it. I'm self taught so I'm always working on filling out my skills.
I think lots of time junior developers trying to copy paste code snippets from examples or article and execute it without understanding the flow or logic behind it. This makes them frustrated when they have to deal with a complex situation.
Don't just copy paste code snippets, try to understand and figure out logic behind it.
I'd say a junior developer is someone who is still learning to appreciate the perils of software development. Who has shipped one or less projects. Who is still doing relatively small tasks for the project. Who cannot yet be trusted to be left alone or to lead a major undertaking. Who doesn't have a deep understanding of concurrency, transactional integrity and other fundamental but a bit obscure issues.
An intermediate developer is capable of doing medium features. Has some autonomy. Has proven herself to be a valuable member of a team. But still doesn't have enough experience to make major architectural calls.
A senior developer is someone with all kinds of war scars. Who has intuition on major design questions. Who has made a lot of mistakes and learned from them. Who has gone through several technology fads.