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?
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.
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 :)
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.
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.
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.
Better conversational skills. I listened to this talk this morning and I really liked it:
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.
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.
The basics of IP networking: DNS, DHCP, routes, gateways, sockets, hops, latency, ping, telnet, etc.
How to use the command line
When to ask for help
Walk in the customer's shoes. Writing use cases as documentation helps me stay properly user-oriented.
Setting up a new environment from scratch.
Writing is something I look back on in my own career and wish I focused on more.
Programming in your sleep.
This thread is gold!
Reading and understanding code.
Do a lot of this. You will become an even better programmer and gain deeper insights to the program you're reading.
Communication, critical evaluation, debugging, sysadmin, data-structures, possibly algorithms.
How to sell yourself to an employer.