This is a guest blog post from Allan Wintersieck. Enjoy.
Dear new developer,
I realize that just trying to learn basic programming principles can feel daunting enough, but if I may, I’d recommend adding one more task to your list: learn a little bit about network engineering.
Networking underpins everything web and app developers do, since almost every web app communicates from the frontend to the backend regularly. Most developers understand the basics of making API calls and how data flows over the internet, but taking a small dive deeper will help you debug issues for years to come.
The goal is to build your underlying knowledge so that when you encounter related issues in the future, you understand enough about how it all works to intelligently tackle the problem. For example: the reason everyone complains about CORS (Cross-Origin Resource Sharing) being confusing is because it doesn’t make sense without first understanding the basic principles of networking and security.
A quick list to get you started:
Read up on the basics of routing. No need to dive into how the protocols work, but understand why it’s set up this way and how internet traffic gets to where it needs to go.
Read the basics of DNS, and understand how a DNS request is resolved.
Read a brief rundown of the OSI model. Focus on understanding one or two examples of things you’ve dealt with in the past that exist at each layer.
Review the difference between TCP/IP and HTTP, and why they exist at different layers in the model.
An overall analogy that I find helpful: networking is like sending mail via the postal service.
Routing is the process of putting mail in your mailbox, having a postal worker pick it up, and it eventually reaching its destination.
DNS is the process of looking up someone’s mailing address so you can send them mail.
The OSI model is a fancy name for making it clear that there’s a lot of details the postal service takes care of for us. Most people understand how addresses and mailboxes work (let’s call that the equivalent to the Application layer), but don’t really understand all the internal details of how the postal service gets your mail to its destination. All those details are the first 6 layers of the model.
With that background knowledge in place, tackle some of these additional questions to lead you to more learning:
How do CDNs (Content Delivery Networks) work?
What’s the difference between “regular” HTTP and WebSockets?
How does SSL (HTTPS vs. HTTP) work, at a high level?
What can nginx be used for?
And as a last exercise, sketch out a complete picture of a work app or side project: what DNS calls get made, what servers are involved, are there any proxies, what protocols are in use, what OSI layer those protocols exist on, etc.
I promise that spending the first few years of my career as a network engineer only slightly biases me towards learning this stuff.
Allan Wintersieck is the CTO and co-founder of Devetry, a software consultancy in Denver that provides strategic partnership for software architecture and engineering.
This is a guest blog post from Don Abrams, lightly edited. Enjoy.
Dear new developer,
When starting out, the hard part is balancing two things:
Banging your head against the wall
Additionally, as a new developer you’ll likely be encountering something for the first time: a codebase that is really really large. Like large enough no one knows all of it. You’ll want to learn how to navigate the codebase ASAP. Every place is different. If you can checkout all the code and get the product running in less than a day, you’re at a world-class shop. If it’s more than a week, I’m sorry.
After you learn to navigate the code, my recommendation is then to learn and copy the patterns that other team members use. So your questions should mostly be “how did someone solve this before?” or “hey, have you seen anything like this before?” If you look at the code they referenced and still have questions, then bring it back up ASAP.
If someone offers to pair, DO IT! Tip on pairing as a junior: be the keyboard and basically have them tell you what to do. You’ll learn how they think about the codebase and learn to navigate it better. You’ll feel stupid when they tell you “just” to do something, but those are the things you need to know. (“just XXX” signals that XXX is complex thing that you’ll take for granted soon– documenting those will really help the next junior).
I also recommend reading a LOT of code.Then, as you get a better command of the codebase and team patterns (3-6 months), you can start asking questions like “why did someone solve this before this way?”
That’s when it gets fun.
Don Abrams has over 10 years of software development experience and recently moved to France.
‘Passion is one great force that unleashes creativity, because if you’re passionate about something, then you’re more willing to take risks’
Dear new developer,
I’ve always taken the quote above to heart… fast-shooting myself into the named camp of ‘Career Switchers` when talking about entry into the world of development. I’ve majored in Mechanical Engineer, spent 10 years in the Oil Industry, and just the last year and a half, really immersed myself into development.
I started at a Bootcamp part-time, got the certificate, quit my job, moved to a new city, worked as a Bootcamp TA and then finally landed my first job as an Associate Developer. It definitely wasn’t an easy journey, but I was passionate about this new life decision and I became obsessed. If not for the passion that led to a slight obsession, it would have been 10x harder to get to where I am.
For a new developer starting out, I’d love to tell you that it will turn out just fine… it mostly does… if you are passionate and have the drive. Learning new technology is not the only thing you should do to give you the edge. You must also go out, meet people, network, make projects, breathe… and then repeat. Learn the technology by finding out how it works more so than just watching tutorials. Meet the community and find coding and project buddies. Make projects for ideas to improve your life, or the life of others.
What I found most helpful in this whole process is having a mentor. Find a like-minded individual that is genuine and genuinely wants to be invested in your new journey. There is so much experience and knowledge that can be shared between both individuals, it truly is a beneficial experience for all involved.
Again, never stop learning, doing, networking and above all, doing what you do, what you are passionate about. The light at the end of the tunnel starts to get brighter and brighter with each passing day, have faith and take the risks! Life is too short otherwise.
Jenn Chu is a software Developer passionate about good design and building simple solutions that will enhance theend user’s experience. She is most excited to bring the diverse community together through collaboration, communication, and connections.
‘You get what you give’ isn’t just a late ’90s catchy pop song set in a late ’90s mall that gives me late ’90s cringe (and nostalgia, but those go hand-in-hand, eh?). It’s also a great way to approach your career! This is something core to the tech scene I’ve adopted in Boulder, Colorado as codified by Techstars with their Give First rule in their Code of Conduct. Their other rules are great ones to build your career around, too.
I have found that giving provides many benefits to the giver:
Offering to help engenders a greater sense of observation and consideration of others’ needs and feelings. This is something we all can work on, given our reputation as social introverts.
It feels good to help others with no strings attached.
If you want to attach (small) strings for your own motivation, you increase how others view you in a positive light.
You may/likely will find rewarding hobbies, coding interests, or other intrinsic rewards without much effort.
You become less arrogant.
You help build your community in a positive way, no matter how small the give is.
People are quicker to recommend you for a job or position if you ever fall on harder times.
It improves your own sense of self-worth and confidence.
You make more friends outside of work.
Did I mention that it just feels good?
My one caveat: There are always people who will take advantage, do try to be open-minded and kind, but watch out for takers, they will burn you out! Thankfully, they are few and far between.
Another great example of this is Jason Cole’s “Year of Giving Dangerously”. I must add that this way of living is out of reach for you as a new developer, but something to keep in mind for over the course of your career. Give in small ways until you can give in bigger ways!
Also, be aware that being seen as only a taker is not a good thing. See my caveat above and think back on any time in your life that you’ve ran into one. Maybe someone who always wanted to copy your answers or homework, but never contributed? Or those group projects where you felt like you were doing all the work? Don’t be a taker.
Volunteer in your community. Be the good you want to see in the world.
Right now, it’s Q1 2019. And there’s a lot of advice you’ll find out here on the internet. Much of it is good, some of it is bad, but the important thing to note is that these are all points of view from people. From that person to be specific. This letter is no different, this is just my view on what matters. Take it or leave it. In fact, that’s the first point I want to make.
2019 tech is full of voices. Social media, popular blogs, and news sites amplify voices and feelings. This is an awesome thing, but remember that loud views aren’t necessarily right.
Find yourself in all these voices. It’s not easy, and it will take time. But work on what you value, and develop your skills to who you want to be. It’s ok if you want to work by yourself on speeding up a search by .01 milliseconds. It’s equally ok if you want to ship a single page app with a brilliant user experience. Listen to the voices when they help, and ignore them when they don’t.
To help find yourself, focus on finding customers that value what you do. Most of the time, these customers are the people in the company you’re working for. But if you want to do algorithms, find people who will value that work. If you want to work on networks, find companies who need that.
It sounds obvious, but it’s an easy thing to miss when you’re looking for a job, and when you’re evaluating comp, culture, benefits, and offices. It’s also really hard to gauge from the outside of a company.
On that note, remember that the 2019 tech industry isn’t how it will always be. Right now, the job market is stellar. I mean really stellar. In most big cities, you can find a job doing just about anything you want, most of the time within a few days.
This won’t always be the case. It wasn’t years ago, and everything comes in cycles. That’s the 2nd point. Be willing to do things you didn’t think you wanted to. I worked on embedded systems when I started my career. I got into web technology not because I cared about it, but because it helped me get a job in a city I wanted to live. Turned out to a prescient choice, and opened up tons of opportunities I wouldn’t have had otherwise.
The tech choices come in cycles, but so does demand. I said before that the job market is stellar. But some of us old timers have been through the downturns. When you’re unemployed for 6 months because literally no one is hiring. When your choice is between a 50% pay cut, or a 100% pay cut. Be wise, be smart. It’s a great time to be in tech, but plan ahead for the times that are tough.
Finally, my last point is to remember that there is a world outside of tech. It’s hard when you’re in it to see that. When tech was smaller, and more insular, it was easier to remember that this is a job.
But now, tech is everywhere. Apps are everywhere. The internet is everywhere. More people are writing code, building companies, and figuring things out. But, tech is not the entirety of life. Get outside of the tech zone, and connect with people who aren’t in it. It will change how you think, and how you develop code. And it provides a much needed break from the echo chamber that is tech.
Good luck, and have fun!
Rishi Malik is the founder of Backstop.it, a company focused on making cybersecurity easy for companies to implement.
This is a guest blog post from Rick Manelius. Enjoy.
Dear new developer,
Can you name all 50 US states? How about their capitals? Every city in the US? Every town? Could you list the GPS coordinates of every coffee shop?
Of course, you can’t, wouldn’t, and don’t. It would be absurd to spend the time and effort to memorize such a vast amount of information that you can Google within seconds. Yet developers often fall into the trap of over preparing and learning a myriad of facts and syntax trivia for a new programming language or framework before diving in and getting their hands dirty.
A personal example: When I landed my first contract as a web developer, I recommended Drupal for the client’s project. However, I was deathly afraid of not being able to address any questions that might come up. To satisfy my “need to know it all” before I put forth an initial proposal, I purchased have a dozen ebooks and read the more popular ones cover to cover several times. Meanwhile, I was only dabbling in writing code by following the tutorials. Unfortunately, this was about as effective as trying to learn a foreign language without a practice partner. The information was forgotten almost as soon as I learned it.
I contrast this with how quickly my experience and skills grew when I started to give myself the permission to play, to test, to tinker, and to interact with the community through IRC and the issue queue. It was there that I would run into a blocker and use those eBooks as a useful resource because I had a specific purpose in mind. Moreover, when I couldn’t find my answer there or with Google, I could lean on others that were actively learning, growing, and sharing along their career trajectory.
Each of the boxes represents a different subject matter. Each of these subject matters has additional, hidden complexity. Also, within that, there might be subsystems that maybe only a few core maintainers of that specific project would understand. Each box may take a day or a week to learn the basics, but perhaps months to years to master.
Trying to do that for every topic becomes an overwhelming investment of time for increasingly diminishing returns. It’s equivalent to learning the GPS coordinates of every coffee shop in the US.
To make matters worse, this infographic only represents the hard skills necessary to produce and maintain the software and its supporting infrastructure. It says nothing about the soft skills of how to participate and grow a high-performance team, how to make solid architectural choices, how open source governance works, how to handle change and release management, how to apply different project management methodologies, etc.
Before I overwhelm you any further…
…there is hope.
You don’t need to know it all. In fact, some of the most successful developers I’ve come to know are skilled searchers and askers. They may not know the information, but they know where it could be. They know how to parse documentation to find the salient details they need to accomplish the task at hand. They have a network of colleagues in other specializations that they can lean on for help. They are confident in asking even basic questions (gasp) in public, because while it may seem obvious for many, there is always at least 1 other person who has the same question.
Let’s look at the medical profession for inspiration. While they all go to school for 6-12 years to gain a base level proficiency, they can then either stick to general practice or hone in on a dizzying array of specialties. When we get sick, we start by going to our primary care doctor. Their goal is to identify and solve the problem there, or narrow down the answer space and refer you to a specialist. Unfortunately, even the specialists don’t always know what the issue is. This is why people sometimes need 2nd or 3rd opinions.
The good news is that in software we don’t need to go to a school for a decade to get started with experimentation or specialization. We are one tutorial and terminal prompt away from trying a new language or checking out a new library and testing it in a local sandbox where little to no damage can be done. There is so much power in this! And it’s also where it can be overwhelming given the 28 million public code repositories on GitHub alone.
Adopt a Hive Mind Approach
We live in a golden age of sharing and collaboration. Developers from all around the world ask and answer questions on Stack Overflow. They write tutorials and howtos on their blogs or Medium. In any given city, there may be anywhere from 1 to 20 tech Meetups a week. There are podcasts, Reddit channels, newsletter aggregators, and active conversations on Twitter.
By asking, discussing, and sharing openly in one or more of these venues, you are adopting a hive mind approach. You are both able to contribute to and receive ideas, perspectives, and solutions. It’s hard to overstate the importance of this strategy and mindset. In my experience, it’s many times more valuable than reading the 3rd or 4th ebook on a given subject (although these are often a useful reference). Beyond just discovering technical solutions, interactions with other developers often result in friendships that can last well beyond the burning framework question you had when you first met them.
So my advice (take it or leave it) is to abandon the lone wolf, know-it-all approach to software development. Instead, learn to contribute to and draw from the collective skills, talents, and experience from our fantastic community that is literally all around you IF you are willing to connect with them.
Final point. I stayed isolated for years until I broke into the Drupal community. Once I did, my career rapidly transformed. I wrote about that here.
So get out there! And good luck!
Rick Manelius is an MIT engineer turned web developer turned startup CXO (operations, product, and technology). You can connect and learn more on his personal blog and his LinkedIn profile.
Be comfortable with being uncomfortable. You’ll never know all the things. And that’s ok.
Ask questions – at the right time. There’s a fine line between reaching out for help too early and too late. Struggling is imperative to growth, but reaching out for answers too soon significantly hinders it. You’ll better understand where that line lives over time.
“Stand on the shoulders of giants.” More than likely, your problem has already been solved. Don’t be afraid of trying other’s solutions if it makes sense for your implementation. But do take the time to fully understand why and how it works.
Be persistent. Programming is difficult and often times frustrating. Don’t give up. The feeling of figuring things out after a struggle is amazing.
Network. Talk to devs at, below, and above your skill level. Opportunities can present themselves in mysterious ways. Utilize your network to not only help yourself, but more importantly to help others.
Jesse Ling is a motivated and relentless problem solver, and a recent Turing School graduate seeking web development opportunities.