Occasionally someone will ask me about software engineering. Why did I choose that field? Did I have to go to school specifically for it? What programming languages do I recommend learning first? Answering questions about an entire career field in a five-minute time span is difficult, so this article is intended to be supplemental to that conversation. Below I have captured advice, anecdotes, pain points, annoyances, and any other whimsical fancy that came to me on the subject, all of which I would love to have imparted on my younger self. So if you are interested in software engineering and want some advice, read on (these are in no particular order, so feel free to grab any heading that interests you). 

Be cautious of extreme statements

As you explore and learn in the field you are going to spend a lot of time online. There is a lot of money to be made (and being made) on the Internet. Much of that money flows through click volume. Since emotions are a good source of clicks, content creators oftentimes harness this and use emotionally-driven language to elicit fear or anger and acquire traffic. Technical writers are sometimes no different in this regard. Content titles such as "Artificial Intelligence will take all programmer jobs" or "All the things you are doing wrong in <insert some programming language>" appeal to fear and doubt. These should act as a red flag that you're in a danger zone for bad advice. More than likely the author of that article is primarily interested in getting your views through emotional appeal, rather than through the quality of writing and information content. 

Summary: find content that balances strong technical competence with well reasoned language, such as:

• Scott Hanselman
• Geeks for Geeks
• InfoQ Podcasts and Blogs

Which language should you learn?

The short answer is: it's not the best question. To succeed as a software engineer you will probably have to learn multiple languages, though you will go deeper with some more than others. A better question might be: which language should you learn first?

Because you will work in multiple languages over your career, there is a lot of leeway. Here would be my criteria:

• First, I recommend trying out several to start. By experimenting with a few languages you might find one that feels more intuitive to how you think. Eventually, plan on trying to go deep with one at some point. Languages are so nuanced, to be truly good at one you need to spend a few years programming in that one language, studying its paradigms, flows, and surrounding technical stacks.
  
  
• Second, it would also be wise to learn a relevant language. Stack Overflow publishes survey results of the most loved languages each year. The 2020 survey is here for example. I recommend looking through this list and giving a couple of the top languages a try.
  
  
• Third, at the very beginning I recommend starting with a simple language. Many people will disagree with me, but my pedagogical reasoning is this: a simple language will give you quick feedback and help you gain some momentum. You can learn quickly and have fun and then, after a bit of a crash course, you can dive into more difficult concepts. 

My favorite language is Python because it is simple but powerful. I've used Python for data analysis, background processes, web development, and machine learning. I've also written a fair amount in C, C#, Java, and  JavaScript. If not Python, I recommend JavaScript, C# or Java, as all three are  relevant, fairly easy as far as languages go, and somewhat analogous syntactically. This is more so with C# and Java and less with JavaScript, but there are still comparisons. 

Summary: Experiment with different languages, but try to go deep with at least one. Here are some great starting points for my favorite languages:

• Real Python Intro Tutorial
• Microsoft's Beginner Guide to C#
• Introduction to HTML, CSS, and JavaScript 
• Tutorial on All Three: HTML, CSS, and JavaScript

Learn to Think in Mental Models and Patterns

Software Engineering is a lot about mental models and design patterns. It's about having the right analogy to solve the problem and then taking the tactical competencies (read programming language) and applying this idea. I remember in graduate school that many concepts were explained by giving some kind of real world example that may or may not have directly applied to the physical concepts we were learning. Because the human brain tends to do generalization well, the concept of design patterns comes into play in programming. You see, certain problems keep appearing again and again. And the solutions to those problems, while differing somewhat, can oftentimes be solved in a similar matter. For example, think about the idea of inventory in a business. It's a common problem with any new business that deals with a physical product: eventually, you will need to manage your inventory. If you want to manage your inventory with software, there are certain, well known, solutions to managing inventory. While that isn't itself a design pattern, common design patterns (usually several) come into play when solving the inventory problem. 

Summary: Many problems follow patterns. Learn the patterns of the solutions that solve those problems. Two good books on this are Super Thinking and Design Patterns. For beginners, I recommend the former. Design patterns will apply more as you go deep with a language. 

Go Deep

Speaking of going deep, this is another one of those general life lessons, but if you're going to do well, you will eventually have to stop pretending to know what you're doing and actually become competent. In my humble opinion, a life hacked together is not a great one. Instead, and this applies to whatever career you go into, become really good; be the biggest badass in your profession that your hard work and talents allow. Software engineering is complex and (while very enjoyable), it is most enjoyable when you understand the rules of the game and can play the game to the limits. To do that, you must become a disciple of the craft and study the technical scriptures. You must observe the teachers and practitioners in their daily habits (read "other engineers") and then emulate what you see.

Summary: Be really good at what you do. It is completely worth it. A great roadmap to competency for a software engineer is the Programmer Competency Matrix. Some good books on this subject are Cal Newport's Deep Work and So Good They Can't Ignore You. If you can only read one, I recommend the latter.

Find a Mentor

This one is tough, but you will find your journey more fulfilling and enriched if you find one or more mentors. Seek someone you admire in the field and ask them to help you. Get their feedback and let them speak into your journey. Note that many people have the natural reaction of thinking that no one would want to take the time to give them advice, but this is actually quite wrong. Many people who have walked the difficult paths to become successful are very happy to share their wisdom. In these cases it is best if you can find someone who actually knows you, but if that isn't possible I recommend closely following a trusted programming personality online. 

Note also that mentors will change over time. Sometimes you outgrow them and sometimes things aren't a good fit. 

Summary: you will avoid a lot of pain and suffering and advance in your career much quicker if you find a mentor. Two practical tips:

1. Don't be afraid to seek out and ask someone to mentor you. 
2. Set a time limit (like 6 or 12 months) on any mentorships you acquire. This allows for reasonable expectations to be set. 

Get Feedback from Critics

This one is slightly different from the mentor tip, but related. Specifically, it is about obtaining feedback from a broader community. You may or may not like the people in this community. That's not what it's about. Getting feedback from critics means putting your work out there and seeing what comes back, even if it's brutal (don't worry, you won't die from brutal feedback). It's about putting your craft above your pride and realizing that unless you obtain the input of others, you cannot ultimately become better. Other people will see your flaws, even if they tell you in an unkind way.

Summary: Get feedback whenever possible, even if it hurts. You will have many blindspots at the beginning and to get better you need others to point them out.

1. Ask questions on StackOverflow (but follow their rules)
2. Work on a project with others and ask them to give you a code review

Don't Chase Fads / Practice

Similar to avoiding people who use extreme statements, I recommend being aware of fads. Life is short, but it's not that short. Tech changes fast, but not that fast. Try to avoid chasing fads. Instead, dig into deeper questions about yourself and ask what your bigger goals are for life. From that, you can make choices about what you will pursue. I rolled this into the idea of practicing because practice requires a time investment. Dedicating yourself to writing code means that you will be sacrificing one thing for another (this is the opportunity cost of an investment). Because of that, you may be tempted to try to cheat and get your returns much faster than is possible. Don't cheat yourself by chasing fads. Invest the time and don't let fear of missing out rule you. 

Should I Go to School

I am not going to answer this question here, but I thought I'd at least make a remark or two. Because of the rising cost of tuition I would never advise anyone to go into deep debt for school. However, there are alternative options. Hopefully I can write an article soon on how I was able to get through three degrees (associate's, bachelor's, and master's) with only $7k in debt. For now, I am going to say that school is great and I recommend it. Technically, you don't need it for programming, but it provides a unique view of the world that is difficult to replicate. 

Conclusion

To wrap up, these are not all of my pieces of advice for beginners, but they are some of the better ideas I think I have on the subject. If you have any feedback or other tips you would like to include, feel free to place them in the comments.