SOFTWARE ENGINEER (FULL STACK WEB DEVELOPMENT)

The title of software engineer means that you write code, but that code means much different things across work environments. If you're working at a scrappy startup, you move fast and across the tech stack (from bash to javascript). When you program in a corporate environment, there's more meetings, code reviews, database migrations, and integration testing. The industry you work in usually dictates the programming language, which is a good thing (e.g. imagine the horrors of writing Aerospace flight code with javascript). That said, this guide is my experience as a professional software engineer ranging from being the only engineer on an MVP to being part of a team that's created distributed systems.

Follow these steps

  1. Pick a programming language. Stick with ONE language. Not sure which one to choose? See this link on which programming languages are popular. Pick a well known language and avoid functional languages like Scala or Haskell that are tougher to initially learn. For web development, also avoid performant languages like C++ where you have to worry about memory management. Your goal is to find your first job so you want to maximize your chances by looking for a high ratio of 'number of jobs available' to a lower number of 'available programmers for hire'. For example, if there are 1.5 java programmers for every 1 java programmer job, consider a different language. I recommend looking into Python, Ruby, or Javascript.
    (http://githut.info)
  2. I recommend picking Python as your first language; it's powerful, yet simple to read and write. Go read Zed Shaw's 'Learn Python the Hard Way' and do the exercises (you won't learn just by reading, you need to type out code and run it). You will run into errors and debugging them is the best way to learn (so don't just copy and paste code). You want to be consistent in your programming schedule; try your best to program every single day. Programming for an hour a day is better than 7 hours on a weekend. When learning new concepts, it will be difficult (because humans don't naturally think like computers) and I find that there's diminishing returns on learning. If you hit a wall, go for a walk outside and get some fresh air.
    (https://learnpythonthehardway.org/)
  3. After you're familiar with Python, the next step is learn to build a web application using Django (a large web framework that has helped build apps like Instagram). Read the regular Django tutorial; don't worry if it doesn't all make sense yet. After that, complete the Django Girls Tutorial to build a blog that runs locally on your computer. You will touch on some front end (html, css, javascript), some python/django for the backend, and overall get a feel for how a computer serves data. After going through the motions of creating your web app, you might ask why are we using Django? If you're curious, take a look at a simple micro framework like Flask. As you play around with Flask and build a web app, you might need more features (e.g. a login system, a way to talk to a database). As you add in team members to your project and/or increase the features/complexity, you want a way to standardize everything. You now have Django and that is why it is a larger web framework.
    (https://tutorial.djangogirls.org)
  4. Do the Django REST Framework Tutorial. Of all the libraries you'll use for Django, DRF is very helpful for building backend APIs. You will start to understand how Application Programming Interfaces (APIs) work in getting, updating, deleting, and creating resources. Throughout your career in programming, you will run into countless APIs. Even if you decide to later go into front end dev only, knowing how APIs work will be immensely helpful.
    (http://www.django-rest-framework.org/#tutorial)
  5. Your goal is to start building real projects that you care about. This is how Jobwaffle got started. If you want inspiration, check out 'Coding for Entrepreneurs' where they walk through building real projects. Okay, at this point you can build a relatively straight forward web application. Great job, you're almost there to your first job!
    (https://www.codingforentrepreneurs.com)
  6. This sounds backwards, but for the next few steps I recommend taking a step back to learn some computer science fundamentals. They will pay off in your career growth as a programmer. You will learn about things like 'Big O Notation', which can be explained in a few pages from Gayle Laakmann McDowell's book 'Cracking the Coding Interview'. This is also the book to go to before you start interviewing for software engineering jobs. You will learn about basic data structures (arrays, queues, stacks, linked lists, hash tables) and sorts (mergesort, quicksort, why bubble sort sucks). If you have time, glance at Trees (e.g. breadth-first search, depth-first search). Ideally you will have at least a month to look over this book before applying to your first job. Practice white boarding (writing down answers on paper and pencil while explaining your thought process on how you are tackling a problem); if this sounds painful, I assure you it is. I got wrecked on my first software engineer interview because I did not know about whiteboarding, don't let it happen to you. Go apply to jobs now. If you fail, learn whatever you failed on, then come back again.
    (https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850/)
  7. If you are interested in more front-end development, check out some javascript frameworks or libraries. This could be libraries like jquery, d3, or full end javascript frameworks like React or AngularJS. As a programmer, you always have to keep learning, but beware that front end development is the fast lane for programmers. I learned Angular 1 and by the time I finished understanding it, Angular 2 was released and my knowledge was mostly redundant. Try not to get burnt out chasing the next javascript framework.
  8. Now that you have a Django app running with some nifty javascript, we start to realize this is only the beginning. Watch Kate Heddleston's Full Stack Developer video to get an overview of where Django fits in a traditional web stack. In the future, you have more things to learn about including deploying code consistently, doing integration testing, setting up load balancers to use multiple databases and web servers, logging systems, doing async tasks, setting up an async store, caching, and more. The good news is that in a project that requires all of these tools, you probably won't be the only engineer. Of all the skills that are useful, your most important one now is to learn how to empathize. Remember that everyone writes a bunch of shitty code before they start writing good code. Give the benefit of the doubt that APIs start off beautiful, but business requirements change and deadlines happen. As you do code reviews, consider leaving a positive comment in a pull request instead of only the changes needed.
    (https://www.youtube.com/watch?v=8uxQOzKi3_0)
  9. If javascript is the fast lane for programmers, Linux is the slow lane. This means that I highly recommend reading the book 'How Linux Works: What Every Superuser Should Know'. The knowledge you learn is less likely to change drastically over time. I only wish I read this book sooner. You've been running programs on Linux, but without understanding how Linux really works. After reading this book, you will know how Linux has setup its file directories, many helpful bash commands, what userspace is, how the kernel manages processes and memory, how you can monitor and debug issues, where to look for config files, etc. Even if you have a dedicated devops team, knowing how Linux works is the equivalent of a a front end engineer knowing how backend APIs are built; it will make you better at what you do.
    (https://www.amazon.com/How-Linux-Works-Superuser-Should/dp/1593275676/ref=dp_ob_title_bk)
  10. Now that you have a decent understanding of Linux and the ability to do bash scripts, you might want to look into ways of transforming these often used commands into fabric scripts, Ansible playbooks, Puppet files, or Chef cookbooks. The goal is to be minimize surprises in code deployment. If you get this right, you won't need to reply back "It works fine on my machine". You will catch a lot more bugs before they reach production. The less surprises on production servers, the more you can really enjoy your time away from programming.
  11. If/when you work on very large projects (I'm talking Uber level), the traditional web stack that I mentioned above isn't ideal. You can make it work, but it's not designed for it (relational databases now require sharding, etc). At this point, you'll need to learn about completely different tools made for stream processing. Wait what? Yep, throw out a lot of the stuff you learned. We now use new tools like built specifically for scalability and speed like Kafka, Spark, and NoSQL databases. Why might you need this and what is this solving exactly? Read Confluent's article 'Making Sense of Stream Processing' here to get an introduction.
    (https://www.confluent.io/blog/making-sense-of-stream-processing/)
  12. So after working on a large distributed system, watch this video on lessons learned from scaling Uber. You'll learn more about microservices and run into issues from fanout to too much logging.
    (http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html)