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?
Oldest comments (33)
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.
Better conversational skills. I listened to this talk this morning and I really liked it:
Testing and thinking about your product like a customer would. Keeping a perspective on how every new feature and existing features impact your customer.
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.
Although developing software might seem very different in comparison to, say, constructing a dam or manufacturing a car, it helps to remember that the same disciplined, rigorous and engineering approach necessary to building a good dam or a great car is also necessary to building good software.
Keep in mind that developing software is a creative endeavor and hence all the more challenging to succeed as the scope/scale of the project increase and size of the team grows.
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.
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.
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
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.
Please, for the love of god, learn how to comment appropriately in your language. First, because it makes your life easier when you need to debug. Secondly, it will help other people know your thought process. And finally, it really helps you hammer down theory and make you understand why you are doing what you are doing.
Or, if the context doesn't support commenting, use meaningful (self-explanatory) names for variables and other structures.