By Saul Costa
Recently several amazing visualizations of the various technologies used by web developers in 2017 surfaced on the Interwebs. One of them (geared towards backend developers) is pictured above.
These are great resources for both beginners and experts alike. They clearly lay out what technologies you should be aware of if you want to get a job as a frontend web developer, backend web developer, or system administrator.
But I think they are especially useful to absolute beginners learning their first few lines of code.
Here’s why.
I’ve been programming for over 15 years (I started with QBASIC games at age 8). I consider myself to be a full stack web developer, and as such, everything shown in those visualizations falls into my domain in one way or another.
Now take a good look at those pictures. They’re pretty scary, right? But they’re not a map of everything you need to know to be a developer. Not at all! Do you really think I ― or any developer ― actually knows how to use all this stuff?
Not a chance.
When you’re just getting started with computer programming, it is absolutely overwhelming. You hear about students who can write code in 10 programming languages, meet a fabled Linux guru, or try to keep up as your instructor speeds through dozens of computer science concepts. And like thousands of others, you probably make a very understandable mistake: you think you’re supposed to know everything there is to know about programming.
You’re not. And no one will ever expect you to.
Even after years as a developer, I only know a small fraction of the technologies in those pictures at an “expert” level. I don’t even recognize a few of them! I’ve used maybe half of them at some point or another, but 75% of that usage was probably under an hour total in my life.
But if you sit me down for an hour with any of them, I can probably put it to use. And that’s because I know how to learn like a developer.
As a developer, you will always be fighting a losing battle if you try to stay on top of every new technology. There are just too many of them, and they’re changing faster than ever. At best, you can pick a few to stay up-to-date on.
So rather than spending your time trying to learn every programming language and technology, you should instead learn how to learn like a developer. Here’s what that means:
Learn How to Read Documentation
Here’s an example for Python file input and output. Here’s an example of a similar library in Golang.
See the similarities? Code examples, short summaries, and typed interfaces (if you’re lucky) are your best friends when you’re trying to answer the questions:
- “Can this library accomplish what I want it to?”
- “How do I do what I want to?”
- “Is there a better way to achieve the goal I have in mind?”
Learn How to Read Source Code
Here’s the implementation for a JSON encoder in Python. If part of this library isn’t behaving how you expect, or if the documentation is lacking, reading the code will give you what you need, although (usually) in a less approachable format.
Some tricks I’ve found useful are:
- Github’s code search utility
- REPLs that let you view source code (like Pry for Ruby)
- Cloning open source projects and inserting debug statements to see how they work
Learn How to Debug Code
Debuggers. Break statements. Print statements! Learn how to use them to hone in on issues in your code, because that’s what you’re going to spend most of your time doing. Some useful things to keep in mind are:
- When you start on a bug, think as far outside the box as possible. What if it’s not the code at all, but the server it’s running on? Or some malformed data? If you cannot smell the bug right away, you’re probably looking in the wrong place.
- Take a break. When you’re debugging, you can easily get tunnel vision on where you think the bug is, and completely miss where it actually is. To geek out for a minute, don’t ever forget that your brain is essentially “just” a series of connected wires, so if you go too far down one path, it’s difficult to jump to a parallel path that might be the one you’re actually looking for. So get up, think about something else, and let your brain reset. When you come back, the bug will be staring you in the face. Guaranteed.
- The code is (almost) always right. It’s doing exactly what you told it to, which is both a blessing and a curse. You just need to find the place you (or someone — looking at you Steve!) told it to do the wrong thing.
Learn How to Ask For Help
This isn’t as cheesy as it sounds. There are plenty of great places to get help when you are stuck. My order typically is:
- StackOverflow (usually found from Google)
- The library’s Github issues section
When you’re asking others for help, here are some good things to remember:
- People helping you will not know much (if anything) about your specific problem. Provide them the necessary context, but don’t overload them. This can sometimes mean including parts of your code, application logs, program configurations, or any nuances specific to your use case.
- Keep it clean. It’s hard to read a bug report full of misspellings, unformatted code, and never ending issue descriptions.
- Don’t post sensitive data. Triple check your post for passwords, access tokens, and user data. And if you do make a mistake, take responsibility and address it as quickly as possible.
Conclusion
As a developer, there is too much out there to master everything. Don’t even try. Learn how you work best as a developer, build a toolset that fits you, and don’t try to have all the answers. Focus on learning how to find the answers quickly.
Whether you’re just getting started with coding or your fingers are already well worn by your favorite mechanical keyboard, I hope this post has been useful for you.
Remember: No one expects you to know everything. Have fun, and never stop learning.
If you want to talk coding, you can find me on Twitter. Or if you’d like to learn something new today, you can take a FREE course on next.xyz!
Happy coding!
Originally published on Medium here.
Top comments (11)
This was soooooo encouraging. I'm not new at development, but was lately feeling kinda "down" about having to learn (and retain) so much.
Side note: someone should write a "Learning how to learn" for developers.
Look up Learning How To Learn on Coursera - that should keep you gainfully occupied for a while ...
Glad you enjoyed it! That's a great idea... maybe a follow up soon :)
Excellent advice, and don't forget the rubber duck debugging technique: explain your problem to someone (or something) else, and you may well spot the bug yourself as you talk. en.wikipedia.org/wiki/Rubber_duck_...
I am in the process of Learning How To Learn for the past 2 months. I will certainly write about it to share it with anyone interested.
Learning how to learn is VERY hard and you'd be surprised the amount of obstacles I face every day!
A bit of advice for now : don't lose sight over the goal!
Need to add to that list of
Something I don't think a lot of new coders are taught soon enough is that there is more than one way to get passing code, and more than one way to approach a problem.
Sure there are ways that are just ugly, or brute-force, or are re-covering old ground. But also some of the new technologies or experiments do exactly the same things as old ones, in new ways. That can be interesting to find out about, and pay dividends as a coder.
As an example one piece of my software stores a history of objects, and attached metadata.
Technically it can store anything, but others have solutions I can use and don't have to spend as much effort developing or maintaining.
The software it integrates with stores it's main DB in an RDBMS. To stop loading that system up with edge-case data or things we don't need an RDBMS for (separate documents, anything non-set based), it uses a separate storage for history and non-searchable data.
That same metadata service is used for prototyping. You send data in and get data out trivially compared to an SQL store or something more robust.
It doesn't make a lot of decisions, just "Have I got data?", oh I'll store {X} in {Y} (directly addressable vs searchable). You'd be surprised to know how fast it is to say store {X}, in {Y}, get {value} from {key}, than given {A,B,C,D,E,F,G} find me {X}, check if it exists, etc (what most CRUD systems do).
When we have context for decisions of system design, or data-structures we can make smarter choices. We're able to composite ideas that others have pre-verified to make a new cool thing that helps solve problems for people, feel good about ourselves, get paid & get things done!
Well done, I feel like to many times people new to development are scared away by the endless mountain of technology and mountains of concepts. As you stated, it is about learning to look, at and know how to leverage, a technology applying some basic concepts; documentation, patterns, debugging, and asking for help.
Couldn't agree more. I learned pretty quickly that its entirely unreasonable for either myself or an employer to expect I know everything. However, I do expect myself to be able to pick up pretty much anything by using my trained problem solving mind to get out of a sticky situation.
Just starting out on programming and this chart is awesome! Makes things so clear. I can see my learning path before me now haha
This should be made Programming 101 for every developer.
excellent material, thank you for sharing your experience for the people we initiate is very useful