DEV Community 👩‍💻👨‍💻

Colin Morgan
Colin Morgan

Posted on

Often neglected skills new devs should learn?

Obviously learning to program is only one part of the equation when learning to become a Developer.

What are some skills, concepts, tools, etc that often seem neglected and should be learned by new/junior developers to help them in the early parts of their career?

Top comments (36)

alanmbarr profile image
Alan Barr

Testing and thinking about your product like a customer would. Keeping a perspective on how every new feature and existing features impact your customer.

colinmtech profile image
Colin Morgan

I'll kick off the discussion with something I think is important and often neglected.

The majority of self learned development takes place locally, which leads to a lack of understanding of how to work on remote servers. I think learning the ins and outs of using SSH to work in remote Linux environments is an important skill new Developers should learn. With this you get the added bonus of learning tools like SCP to learn how to quickly move files around.

thecodetrane profile image
Michael Cain

Yes, and FWIW you can learn those skills by working in Linux locally (I’m a recent convert from Mac).

mbtts profile image

You don‘t need to switch from a Mac to learn those skills.
You can learn on a mac just fine, it is still *nix.

gameguy43 profile image
Parker Phinney

How to ask for help.

The thing people get wrong: it's important to be able to say very specifically which piece you're not understanding, or what part of your code is breaking.


  • "What's this method for?" (uhhh, did you read it?)
  • "My code's not working." (uhhh, what have you tried?)


  • "I see we have this method and this method, but as far as I can see they're doing the same thing. What's the difference between the two?"
  • "Can you help me with this? On this line I call this, and I expect the output to be x, but as you can see when I log it here I get y instead."
willdestijl profile image

Here's THE long-standing article that addresses this in depth - in a way that applies to tech generally (beyond dev). Parts seem archaic. It's a Wiki, so overly wordy, etc. But still pretty great overall:

jcopella profile image
John Copella

Unless you're in a Windows-only shop, I'd suggest a fairly deep dive into the Unix shell(s), in both major forms -- sh & csh.

Understand when the various dotfiles are executed, and in what sequence.

Understand the environment and environment variables.

Learn how to write a shell script -- know what the shebang is and what it's for, know how to parse and process arguments, write an if/then/else block, write a for-loop, handle errors, check and set the exit status, etc.

Know the bread and butter commands, really, really well: ls, cp, rm, grep, etc. Read the man page for each and learn each and every option. Odds are you'll need them at some point, eventually.

Learn fundamentals of job and process management. Know how to move jobs from the foreground to the background, get the process ID of an executing program, send a signal to it, etc.

Know the difference between a shell built-in and an executable command (program). Know how the PATH is used, how to change it, and why.

Know how to inspect and set permissions on files.

Invest the time to learn regular expressions, and the tools built on them: sed, grep, and awk.

Know the shell's quoting rules: understand the difference between a single-quote and a double-quote and a back-quote.

Spend some time learning I/O redirection: know the difference between > and >>, etc. and know the difference between stdin, stdout, and stderr.

Figure out how the history works, how to recall previous commands and how to edit them.

I see a lot of new developers with just the barest, most superficial knowledge of these things and it's really a hindrance. The shell is a very powerful tool and can save you enormous amounts of time and energy. Time spent in learning it repays dividends many times over throughout your career.

quii profile image
Chris James


So many teams have suffered from people lacking empathy and it sours relationships.

Software development for anything non-trivial is a team sport and as such you need to be able to work with people effectively.

In more concrete terms: See some code you dont like? Rather than yelling loudly and complaining think about the circumstances of how that could've happened.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

jlr7245 profile image
J Silverstein

I used to teach at a developer bootcamp and the first homework assignment I always gave the students was to watch MPJ's wonderful video Does a Developer Need to be Nice? and write a little reflection on it. It's such an important skill to have.

ferricoxide profile image
Thomas H Jones II

Hell... Even absent working on a team, when you have to revisit code you wrote "a long time ago" (frankly, anything you've been wholly divorced from more than a month or two), you'll find those kinds of things in your own code. There's been more than a few times where, if I hadn't commented why I made a given choice, I'd be asking myself "dafuq were you thinking with this???"

In general, when you have a question about anyone's coding choices - even your own - ask why that choice was made. It's a lot less accusatory to ask about the decision-basis than just shred and provides opportunity for both parties to learn.

jvanbruegge profile image
Jan van Brügge

Having a toolbelt of languages that you keep "maintained". Often I meet people that say: " I know Javascript and I can use it in Node, so I will use it for everything". Languages are always good in one part of the problem space and bad in another. My personal toolbelt consists of Haskell for Servers, Typescript for UI (and UI only) and Rust for low level code.

Not accepting that development is constant learning. I know people that shy away from new ideas or unknown odeas because they are either not directly useful for their current work or just because they dont have to. I think you should go out there and try something new. Even if you cant use it directly in your day job (e.g. learning a functional language), it will benefit you in some way (e.g. writing the new concurrent something™ in a functional manner).

Using a search engine. Seriously, I am happy to help anyone who is stuck with a problem if he has tried to solve it themself for ~30min. Most of the questions I get vould be prevented. It's a win-win, you feel empowered, being able to solve problems on your own and I dont have to reply to the same answers again and again.

Actually understanding what dependencies do. Adding dependencies is always adding technical debt and this fine as long as you pay back the debt! You should be able to say: "I ahould be able to implement this library on my own. Not as well tested and bug free, but I understand the core algorithms". People programming in languages with large package repositories often fall into this trap.

And my last one: Magic is evil, stay as far away from magic as you can. Arthur C. Clarke said: "Magic's just science that we don't understand yet." This is so true when programming. Magic is cool when it works, but once it breaks you have no idea how to solve it. If someone advertises something as magic (e.g. framework features), run. If you think something is magic, ask how it works. If no one knows, run too.

thecodetrane profile image
Michael Cain

The book that changed my life was “Mindset” by Carol Dweck. Getting with the idea that “the learning is in the struggle” totally jumpstarted my learning ability and I was able to overcome obstacles faster.

lennartb profile image

1) Reading and understanding. When instructing students or interns I often got asked why their build fails with this or that error, especially when using a new language or framework. Most often the compiler did just tell them what actually was wrong. Uninitialized variable, missing parenthesis, access from static to nonstatic object etc. Take your time to read and understand the error message, try to resolve it by yourself or just google it. If it's something more complicated it's fine to ask, but your problem-solving skills won't get any better if you don't try it for yourself.

2) Debugging. The amount of astonishment when showing them that they can set breakpoints, look into variables or altering the executing flow is astounding.

tomasmuzas profile image
Tomas Mūžas

Definitely agree on 2). I think that was my greatest discovery when I found out that I can set breakpoints and see variable values real time

burdettelamar profile image
Burdette Lamar

I've recently been rewriting the doc for a GitHub project, reorganizing around use cases instead of features. This is a much more user-oriented technique, and has actually caused me to rethink some of the functionality.

Here's my earlier post.

cutiko profile image
Erick Navarro • Edited on

Don't over complicate stuff. KISS and YAGNI are great, but those are about coding, what about features? Yes, MVP and Lean kind of take care of it, but what about a personality trait? This is the developer skill and curse. As devs we like to solve puzzles, bigger puzzles are more rewarding. So when we think about a feature, we tend to consider every complex case. While this can lead to thoughtful analysis it can also lead to confusion. The most common example is when using the one step auth (aka social networks login), devs tend to think: what if the user doesn't want to use their social network email/name as default for my app? Then rush to add fields in the login. The result is making a 1 step signup into a normal tedious account creation. Solution: just let the user log in and then offered them the edit profile functionality, that is gonna be within the scope of the project anyway. Don't get me wrong, this is not the same than don't understand the feature. An example of that mistake would be a miles tracking app and then the dev wonders: what if the user walk backward? Over complicating stuff is part of our skills, we needed to solve all kind of problems, but it can also become a mess.

sublimemarch profile image
Fen Slattery

The basics of accessibility, especially if you're learning web development. It's so much easier to learn the correct, accessible way to write HTML when you're first learning, then it is to go back and unlearn bad habits.

stenpittet profile image
Sten • Edited on

In a previous job we thought a lot about adding the acronym SFTU to the list of core values of companies.

SFTU stands for Seek First To Understand which is something that we found to benefit not only new devs but also old timers.

There's often a knee-jerk reaction when looking at some old code, a feature, a product and point at what's missing or what could have been done better. But more often than not there are several reasons for why it's done the way it is, even if it looks horrendous: it could be MVP code done under pressure to keep the project afloat, it could be that the team had a different focus at the time, it could be that the customer requirements changed, it could be that the team was not well versed in a specific technology... The point that it rarely is because someone wanted to do a sh*t job and it's important to try to understand context. This is especially true, and hard in software development as it's a form of async collaboration that can be happening through many years.

It's quite fitting that the acronym is a permutation away from teaching us to listen to others :)

thecodetrane profile image
Michael Cain • Edited on

Creative and professional writing skills.

I’m dead serious.

One of the hardest things we have to do is name things. It, in itself, is an abstract activity: you are taking an idea and fixing it upon a word or short phrase. No small task! Some of the colloquial method names and error messages I see in projects makes me cringe.

If you can write an essay or a short story, you can probably name things well. Cultivate those skills.

kspeakman profile image
Kasey Speakman

You will write much better software if you do this: Understand the user’s perspective. Users often assume the dev knows more about the uses of the program than they do. But I usually find the opposite is true. Devs know more about how things work internally, but that frequently bears little resemblance to user’s experience with the program. You will write much better software if you make the effort to understand your users. Dev and user are on the same team, each contributing their piece of the solution.

rhymes profile image

Better conversational skills. I listened to this talk this morning and I really liked it:

We are hiring! Do you want to be our Senior Platform Engineer? We're hiring for a Senior Platform Engineer and would love for you to apply.

Head here to learn more about who we're looking for.