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?
Latest comments (33)
How to sell yourself to an employer.
Programming in your sleep.
This thread is gold!
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.
Communication, critical evaluation, debugging, sysadmin, data-structures, possibly algorithms.
Writing is something I look back on in my own career and wish I focused on more.
Walk in the customer's shoes. Writing use cases as documentation helps me stay properly user-oriented.
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.
Setting up a new environment from scratch.
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
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.
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 :)
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.
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.
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.