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.
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:
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?”
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
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.
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.
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.
Originally published on Medium here.
Many times as a mobile developer I have to work on apps without the API ready that was crucial for the feature I was implementing. Either the backend was developed by another team that was not entirely in sync with us or our backend team had no chance to implement those endpoints earlier. For this reason, I was not able to satisfy the Definition of Done but it does not mean that I have implemented the UI only.