These are some notes I wish I had understood early in my career. They provide great overall principles and carry over into other fields besides software engineering.
Investigate the task at hand rigorously
- Try to get as much information as possible, from anyone or anything, about what you are about to do.
- It is your responsibility to accurately model something from the real world into code. As an engineer, you want to code, but remember that all the real work comes before your hands even touch a keyboard. This is where your true value comes from.
- Understanding the domain will allow you to overcome many of the hurdles you might encounter during development. Try to develop the best abstraction for the current problem.
Identify who is affected by the work you are doing
- If you are building for yourself, then only you know what is expected. However, you are almost always building software to provide value for someone else (open source, clients, customers, etc.).
- To most people, what you do is magic. You have a great privilege and responsibility in being able to create systems that people can use. Learn to set expectations of what you can and can not do. This will make you the most reliable person on the team.
Identify who, what and when status should be communicated
- There will always be aspects involved in creation that are not under your control. Know that this will happen, but do not be afraid to communicate that things did not go according to plan.
- Really understand what information you need to convey. You need to understand your audience, so that they can understand you.
- It will always be difficult to assess what needs to be communicated. It is better to lean towards more verbosity, but know that a miscommunication can have dire consequences.
Understand the consequences of software decision making
- Understand that any technology you bring in to your organization is now your responsibility (frameworks, platforms, libraries). Although the software was produced by a third party, you are the one that will benefit from or pay for the bugs or debt the technology brings.
- Don't always give into the latest flavor of the month technologies. These technologies were created and adopted by the people that had the problem that the software intends to solve. In most cases, that is not you.
By the very nature of the word, technology will always be new
- Don't put too much emphasis on what you know or have done with a specific technology. Learn the valuable lessons, but always be willing to redefine what you know.
- Understand programming and computer science fundamentals, as those are one of the few skill sets that actually carry over through any new or old technology.
- ABC: Always be coding. Never get comfortable with where you are, by that point you are already behind. It is up to you to make sure that never happens.
Productivity is often knowing what not to do
- At the end of the day, the only advantage you have is speed. You will often have to fight the urge to try to solve problems you don't have and might never have: scaling, refactoring, UI tweaks, features, etc.
- If it is a real problem, it will happen again. If it doesn't, then it is a problem not worth solving.
- Learn what and when to optimize. Avoid premature optimization. It is better to understand the pains of problems, so that you can understand what the solution needs to be.
Everything you build will need to change
- You can shape the future, but you can never predict it. Since you are modeling logic for a business that is changing, understand that the code base will also have to change.
- A tower is built from the ground up. It is important to have a good foundation. However, your responsibility right now is identifying to the organization that the ground they are on is actually land and not water.