What have I learned after being a software developer for 2 years

I have been a software developer for over 2 years now, almost 3. What have I learned in that time? Oh that list is long and tedious. I have spilled sweat and tears, worn so many hoodies that any 10-year old boy would be jealous and drank so much coffee that it is a wonder I am ever able to sleep normally.

This list will contain my journey, as I try to walk backwards and retrace my steps and notice what I have actually learned. It is not a full list, as it is quite an impossible task to remember all the things I have learned. For that reason I would ask you to write your lessons in the comments below. Did I miss something that you think should be mentioned? What was the biggest lesson for you? 

1. Mostly I have learned about coding. That is obvious and I was expecting that. Actually it was probably the only thing I was expecting to learn.All about the programming language, I thought. If only I knew all about the language. All of the syntax. Then I will be the best. Oh Boy how narrow a view I had at the time. Sure, knowing the languages is necessary. You need to learn how to code in order to be a coder. It does not make you a software developer though. It makes you merely a coder. This will lead me to my second lesson.
2. It is not all about the programming language. The language is not the only thing you need. Actually, it becomes less and less important the more advanced you are. You kind of stop thinking about it and start thinking about other things instead. What other things? Well that will lead us to the third point.
3. Software development is about understanding the context, understanding the customers and understanding the overall picture. It does not matter what type of software you write, they all have their customers and contexts. The more you understand about the context where the system is going to be used, the less mistakes will be made because you understand what is supposed to happen. If you develop python software for the physics department, but you lack basic understanding of what the department is trying to simulate, you will have a hard time estimating whether your software is working or not. So the more you understand about the customers point of view, the easier it is. The customer however might be totally oblivious about the software development process, and you have to learn how to deal with that.
4. The end user won't see the beautifully written code, they will only see the results. If the product works, they really don't care if there are bad variable names or even if the whole architecture is a total mess. They are still quite happy with the product and keep using it. Does this mean that you should write the minimum and shift bad code? Absolutely not. Next point will tell you why.
5. Good code is not written for the customers, but for you and other programmers. You are the one who needs to fix the bugs, add another feature or change the system to work in x,y, and v. Don't make things harder to your future self by writing unscalable systems without tests and a code base riddled with problems. Even if you are not the one who keeps maintaining the system, you might end up maintaining some other system. Show some sympathy to other developers and keep the code clean. You don’t want a system that was developed in a week and it takes that same time to fix a bug. 
6. You are a consultant and you need to utilize your knowledge in cooperation with the end user. The customer may want the fastest possible solution, the quick fixes and whatever makes the most amount of money. It is your job to estimate how bad code you can write for that situation with the knowledge you have. There is software that needs to be top notch, and then there are small games for your nephew. That nephew doesn't want to wait years so that you can finish that ball game! He wants it today, after he has taken a little nap. When you understand this, you understand why good developers might write "bad code" sometimes. This was actually my item in the list, spoilers.
7. Good developers might write "bad code" sometimes. It happens. You are in a hurry. The system doesn't bend easily to those better solutions and the bad solution takes 1/8 of the time that the good solution takes. Which option do you choose? I don't know, you have to learn to estimate things.
8. I mean, you really need to start to estimate a lot of things. How long does it take to perform this task? How about this feature? How about the whole system? How much will it cost? How much time should you spend figuring a,b and c out? What task is more important than the other? What will happen to the system in the future? Should X be considered when building a system? When is a good time to upgrade to X? How much time should you spend learning about the thing?
9. Teammates and customers can make or break a team. I have yet seen a solo project up close, usually people tend to work in teams and for a good reason. It is really important to have someone to bounce ideas around, no matter how good you are. Project can be ruined with uncooperative teammates or customers. Software is not just a solo task and you need to cooperate with other people.  It is worth mentioning that finding a team that works is pure gold! No wonder why some companies hire whole teams at once. 
10. Choose your company wisely. This might be easier said than done, especially if you are looking for the first job, but even then you should focus on certain companies more than others. I am not picking the criteria for you, all I am saying is that it might be a widely different experience between two software development companies that are located right next to each other. Do you want to work for a big company or a small one? What languages and tech stack they mostly use? How about the culture? Don't just go wherever, at least if you have a choice. Guide your career yourself.

Have you learned something that you would like to share?