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 (33)
Testing and thinking about your product like a customer would. Keeping a perspective on how every new feature and existing features impact your customer.
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.
Yes, and FWIW you can learn those skills by working in Linux locally (I’m a recent convert from Mac).
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.
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.
Bad:
Good:
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:
catb.org/esr/faqs/smart-questions....
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.
Empathy.
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.
retrospectivewiki.org/index.php?ti...
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.
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.
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.
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.
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
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.
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.
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.