DEV Community

Cover image for The Golden Rule for Junior Developers
David Wickes
David Wickes

Posted on • Edited on

The Golden Rule for Junior Developers

So this:

is interesting, and it's nice of Ben to boost

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.

And I agree with them... but twelve things? I can't remember twelve things. Nah, you don't need twelve things. You need one thing, a golden rule, a variation on:

ask questions, especially if you think they're not worth being asked

more like

Ask Questions All the Time.

That's all you need. You need to learn to ask questions. You need to learn to weaponize your ignorance.

What? 'Weaponize your ignorance'? What the hell do I mean?

As a new software developer ('junior' whatever - I was in my mid thirties when I started), the fastest way to get anywhere in your career is to acknowledge three things as quickly as possible:

  1. Everyone else should know more that you about software development.
  2. A part of your job is to learn more about software development.
  3. It's a part of everyone else's job to teach you.

It really is. Really.

So to make (2) happen, you need to get (1) to do (3). And you need to do that - actively. Don't wait for other people ('seniors' - they were all younger than me) to create a learning moment for you. Grab those suckas by the collar and say:

What do you mean 'RESTful'?

What the hell is a Dependency Injection Framework when it's at home?

You 'curried' that function? You did what?

Why are you using a PUT instead of a POST?

Whoah, whoah, whoah! What's that curl command you just used?

What shortcut did you just use to make that happen?

Why are you always typing git pull -r? What's the -r for?

Where's that variable coming from?

And if it's hard to ask these questions, ask:

Why can't we pair program more? It's hard for me to learn more if I can't see what you're doing.

And if you get any flak for asking 'stupid' questions:

Why aren't you interested in making me a better developer?

Why do you think I ought to know that? Why do you think it's really basic? Why don't you explain it to me?

Do it everywhere, all the time, for the first two years. Do it when you're programming. Do it when you're in a meeting. Do it when you're at lunch:

Why is that written on your t-shirt?

Take advantage of the fact that you're meant to know nothing at this point in your career - make that ignorance work for you! Ask questions about everything. This is your golden opportunity!

You'll discover that other programmers (for the most part) love talking about programming and ~showing off~ telling you what they know. They actively enjoy it! And, quite often, they won't know - and so you can both have a great excuse to find out the answer together through searching the interwebs - at which point you'll learn how the senior developer gets answers!

Don't NOT Ask Questions

But whatever you do, don't shut up and let that acronym/technique/sentence go unquestioned. You're doing no service to anyone by being quiet: not to yourself, who won't learn anything, and not to your colleagues, who'll think that you know what they're talking about and will be annoyed when later it turns out you don't.

Cultivate Hyper-Curiosity

Be loud in your ignorance! Be curious about everything! Let your mantra be "I don't know - show me". Everything else else you need to know will flow from this one thing. Take this golden opportunity! Weaponize your ignorance.

Because, in a year or so, you won't be able to do this. In a year or so there'll be another new developer in your team asking you the questions. So take advantage of this opportunity.

ask all the things

Top comments (20)

Collapse
 
vitalcog profile image
Chad Windham

I disagree that this stops in a year or two. Always ask. Eventually you'll not be asking "Where does that variable come from?" because you've learned that already and your questions will be "WTF is kubernetes?". But there will still be plenty of things you're ignorant about. Might as well keep it "weaponized" as long as possible ;)

Collapse
 
gypsydave5 profile image
David Wickes

Absolutely - keep it up for as long as you can. My last point was meant to highlight how quickly time passes as a developer, but please don't take it as the end to questions. If anything, the more questions you have answered the more questions you'll have.

Collapse
 
tadman profile image
Scott Tadman

At some point you'll have enough knowledge to know how to answer your own questions, so while you're not asking as many external questions, you're still thinking about things like "Why?" when you work.

Collapse
 
gypsydave5 profile image
David Wickes

This is a good trick for more senior developers: ask the question that you think the less experienced developer is too self conscious to ask even if you think you know the answer. You normalize the asking of questions among your group, helping everyone to feel OK about exposing their ignorance. And you also might get the answer the junior need.

And you'll be surprised - you might not know the answer after all!

Collapse
 
angelainniss profile image
Angela Inniss • Edited

Such a good idea. I'm only 10 months in but this would help. I'll remember this a few years down the line!

Collapse
 
cheetah100 profile image
Peter Harrison

There is certainly a problem with developers not asking questions. The reason is that the status of a developer is to a large extent invested in their intelligence, by which I mean their perceived intelligence in the eyes of others. To ask a question is therefore an implicit admission, both that you don't know something, and that the person you are asking is more intelligent or knowledgeable. Your status is not served by making yourself look like an idiot, right?

Well, the thing is that we know junior developers are inexperienced. We don't give you the hard tasks because you need time to ferment. In order to overcome your natural reluctance to sacrifice whatever meager respect you might have in order to get an answer to a problem you must be prepared to let go of ego. It was a mirage anyway, so don't worry.

Okay, now let that sink in. Don't let your ego get in the way of asking a question. If you sit there and don't achieve anything, or worse do something terribly wrong because you didn't want to look like a fool, you will look bad.

So asking is good? Well not so fast. Asking a question that is thoughtfully posed after having tried to seek the answer independently will be respected. Asking questions every five minutes to answer things that could be found on Google in a minute not so much. Programming is a demonstration on the ability to think and solve problems, so asking too many questions if they are too obvious will only show you up as lazy. Asking questions that are well framed and display a understanding of the problem and a genuine attempt to resolve the issue is better.

So yes, the senior devs do evaluate and judge Juniors, but perhaps not the way you imagine. Don't be afraid to ask, but don't treat the time of your fellow developers with contempt either. Developers at all levels must be prepared to learn from others.

Collapse
 
kikithedeveloper profile image
Kimberly Lin

It is very refreshing to read this article, but my PTSD from my first junior developer job was so traumatizing that I struggle to ask questions out of fear of getting my head bitten. I am already four years in this industry and I still struggle to grow because I almost always learn things on my own. My only problem with your article is that my reality does not make it possible to ask questions. Rather, people at my company tend to keep to themselves and this is this pressure that you have to learn and do everything by yourself. There's this double edge sword in my work culture that if you ask, you are considered below junior. I work at a consulting firm that sadly doesn't really prioritize tech first. What is your best advice up against this work culture?

Collapse
 
gypsydave5 profile image
David Wickes

First up - I'm sorry you're having such a bad time at work. It sounds like a very toxic environment. I was very lucky to be get my first job as a developer surrounded by patient, kind and enthusiastic people who wanted to help me. You have not been so lucky.

I'm going to try and give you some advice, but bear in mind I'm just one person and I'm no expert.

1. Change your job.

If I got this advice I'd just laugh and say "yeah, but I've got to eat". Which is true. But I'm not saying you should quit tomorrow; just make it a goal for the near future. I don't think you'll be able to change your work environment - you might, you never know - but it's very difficult to do this unless you're working from a position of seniority (or have the ear of someone who is senior).

So in the meantime...

2. Reach out

Reach out to your friendly neighbourhood software development community. The world is full of good, kind, patient and enthusiastic people who want to help you and answer your questions. Hopefully some of these people live near you and attend meetups like Girls Who Code or Codebar - but any meetup with a good community and a code of conduct will work out fine. I don't know what you work on (or what you enjoy working on) but try and find a place like that.

The hard part is building a relationship with people you don't see everyday, but you can do it. Put yourself forward, chat, ask for help. Hopefully you will find an environment that will nurture you.

But in the meantime...

3. Post on Dev.to

As @quii just said to me:

You're never alone with the World Wide Web.

Ask questions on here - ask anything on here. Find people posting about things you're interested in and ask them questions. Ask me questions - you already did! This is a good community who will want to help you.

Finally: can I ask for your permission to share this question more widely? It's a really good question and I think the more people you ask, the better the answers.

Good luck!

Collapse
 
ld823 profile image
LD823

Never wait for the junior developer to ask questions.Junior developers often do not know that there is a question to be asked or that there are alternative options. For all they may know, they are doing everything exactly the way it should be done.

I think that senior developers have a responsibility to sit with the junior developer and have the junior developer walk them through their code, when they sense the junior developer struggling. The senior developer can ask them why they did a certain line of code, or suggest alternative methods, or give a line of thought.

It isn't just about being productive, it's about making sure everyone on the team is productive. It is also about everyone feeling good about what they are doing.

Collapse
 
thebigl profile image
Leonard Morrison

I am practically the king when it comes to asking a lot questions. Sometimes, I fear that I may be asking too many questions. When I started applying for jobs as a Software Developer, I never bothered to ask questions and I was always brushed off as a Developer. I always thought that companies think that they don't want somebody who asks too many questions. They want somebody who shuts up and does their job; everything they would ever want to know would be explained when I got hired. That sort of thing. But the fact is that not even Senior Developers know everything about development. I'll continue to ask questions.

Collapse
 
binayakgs profile image
Binayak Gouri Shankar • Edited

When I ask questions, they get irritated or laugh at me. I have stopped asking questions now. I am depressed because of that. I dont know what to do now. I think I am dumb.

Collapse
 
gypsydave5 profile image
David Wickes

That makes me depressed. Don't get depressed - let's take some action!

First action: ask a question here.

That way we can

  • get an answer (maybe)
  • see if we can help frame your questions better (also maybe!)
Collapse
 
kansuler profile image
Simon Wikstrand • Edited

I am sorry to hear that. While i also do encourage questioning, i believe asking a big amount of sporadic questions on relatively simple matters can lead to annoyance among mid/senior developers. Programming is mainly about solving problems, and the work include troubleshooting and testing things yourself. It is what your colleagues expect from a fellow developer regardless of experience. If you can tell them that you've made an effort and it still doesn't work, they would probably be more understanding.

I'd also recommend to ask for a session where you ask many questions at once if you haven't tried that.

Collapse
 
binayakgs profile image
Binayak Gouri Shankar

I ask them questions because they don't have any proper documentation of their projects. Debugging code is fine but I have to go through unnecessary things just to solve one issue. That is actually time-consuming, and after that, they term me as a slow worker. I don't want to work there anymore.

Collapse
 
gypsydave5 profile image
David Wickes

This is true ... there are questions which are driven by curiosity ('how does this work') and there are questions that are more instrumental ('why doesn't this work').

Often the second sort arise because you're missing some deeper understanding of the problem, but even so - one should always try and solve problems oneself (say for 20 minutes), make a list of questions that you run into as you run into them, and then be able to ask them afterwards.

But I also have to say: pair programming is the very best way to ask transmit knowledge and understanding. Your senior pair knows you, sees how you're approaching a problem and will be much more equipped to understand your question as you're both in the same place (literally and metaphorically).

Collapse
 
0leog profile image
Leonardo Garcia • Edited

I could not agree with this post more. I started out 2 years ago right out of college. I had no experience in the tech stack we were using but revved up quickly by asking questions! It truly is your greatest weapon when you are a junior, entry, whatever kind of developer honestly. As a senior if you are switching jobs you may not need to know the tech/language side as much but things run differently at different companies and asking questions about business rules is just as important. Thank you for writing this. I think this topic of asking questions doesn't get as much attention as it should. I even mentioned it here in my reply!

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.
Collapse
 
wolfhoundjesse profile image
Jesse M. Holmes

I've been at my new job for a week, and I've asked the same question to the same person on three different days. Each time I've gotten an even more in-depth answer. As a result, I've leveled up my confidence in what I am doing three times.

Sound advice, @gypsydave5 ! I'll make sure and pass it along to the juniors we are soon hiring!

Collapse
 
binayakgs profile image
Binayak Gouri Shankar

Will do the same very soon. This blog was quite helpful.