And how they can make you a better developer and data scientist…
Last month I finished my 3-month internship at Amazon in London as a Software Dev Engineer. I learnt a lot during this internship, managed to work on some amazing projects, and worked with some brilliant and talented people. I knew I had a lot to learn in terms of programming, but the internship also taught me that coding isn’t the be all and end all of being a Software Engineer or Data Scientist. To this end, here are the three main lessons I learnt while working for Amazon and why/how they will make me a better software engineer or Data Scientist in the future.
Feedback is important
If you want to become a great software developer/engineer, feedback is incredibly important. This doesn’t just include feedback on your code through processes such as code review, but also in 1 to 1s, team meetings and doc reviews. For this to improve your ability as a software engineer you have to be able to take this feedback on board, learn from it and then make sure you use that going forward.
Among the first places I received feedback, before writing any code at all, were 1-to-1 meetings with my manager, mentor, onboarding buddy, and other team members. This feedback included how I was progressing, what I should be paying attention to, and how I was fitting in with the rest of the team. This meant that I quickly adapt, ask questions, and ensure I was heading in the right direction at all times, and meant that I could onboard to the team and become a useful member much more quickly than I would have done otherwise. Onboarding to a new team is often a big ask where a lot of information has to be taken in; with the guidance of what to focus on, I was able to ensure that I was contributing as fast as possible. This continued throughout the internship where later feedback was on how I was progressing or if there was anything I could improve as to how I was tackling problems.
I was able to receive feedback in a team setting through a process of document review. Since Amazon is a customer-driven and -focused company, I had to ensure that any of my ideas or thoughts as to the tool I was tasked to build would be useful for the customer. In my case, since I was building an internal tool, this meant I had to build something that my team would be able to use. The feedback at this stage, where all the team commented on the features, look, and implementation of the project based on a document I had put together, helped to ensure that the final project would be relevant to them. Without this feedback, the project wouldn’t have met the needs of the customer and it would likely have been discarded after I left! Now though, I was put on the right track to ensure that the team could use in the future.
Finally, I also received feedback on my code through the process of code review. This was the first time anyone was giving me direct feedback on my code, the structure, the implementation and how I was writing it. This was certainly a very nerve wracking process, but it managed to greatly improve the final implementation. Several things were picked up, which I tried my best to implement in the next revision and future commits, and helpful hints were suggested for the future. This has directly helped to improve my code quality, and while there is plenty I have left to improve, I hope to think that this will set me up for more future success.
Feedback then is something that I will continue to seek out in the future wherever it is available and appropriate. While I can learn plenty on my own and build some great projects, at the end of the day someone else may have a different viewpoint or experience that will ultimately lead to better code, a better process, and a better product for the customer.
Clean Code
This lesson leads on from the previous one as the process of code and document review showed that clean code is important for creating a lasting and robust product for the customer. This means that the code should be simply implemented, efficient, and readable/understandable by humans. Clean code should flow in a logical manner to the point that someone new to the could base should be able to relatively easily grasp what is going on and the purpose of a piece of code, without too much prior understanding or documentation.
I am not saying documentation or commenting isn’t important, it is, but the code should be able to speak for itself. I still have a lot to learn in this regard but my main takeaway points from this lesson include:
- Variable and function names should state what they are doing or what they are for. They should be clear and easy to understand. If they are not, then your code can be difficult to read and hard to debug, which, when you have a large code base, can make life 10x more difficult. This includes ensuring the naming convention is consistent throughout your code as otherwise things can become messy and unclear.
- A function should only do one thing. If it is doing more than one thing, it should be broken up so that it is easier to understand and test, ultimately ensuring more robust code. Again, this is useful when you have a very large code base as it means you can easily isolate where a bug has appeared and fix it, without having to dive too deep into the code itself.
- File structure and naming is important. This goes hand in hand with the variable and function naming point, but ensuring that it is easy to find code and that similar code is bundled together is important for debugging and understanding what a code base does. This can get more complicated with a large code base but that just makes it even more important when navigating through a variety of files.
- Finally, although not code itself, commits should be for a specific purpose and small. A large commit covering multiple changes to the code base will make it difficult to see where a bug has been introduced and then how to roll the change back if needed. Separating out commits, and clearly stating their purpose, can help with the long-term maintainability of code.
All of this should also fall in line with accepted conventions of the language or purpose that you are writing in or for. This includes maintaining consistency throughout your code base so there is no confusion, especially when you are working on a project with multiple people involved. All of this will ultimately help with the maintainability and improvability of code not just for yourself, but for your whole team.
While I knew a lot of this before the internship, since no one was reviewing or looking at my code I didn’t know if I was missing something or whether what I was doing was correct. It can often be hard to police yourself after a long day of coding and you are not entirely sure what you are looking for. While this does not mean that you shouldn’t hold yourself to a high standard, or that you should depend on others to solve your code, it means that a good team can ensure high standards are kept and that you are constantly learning from each other. The code review process has helped me learn a lot and hopefully improved my code readability and purpose, hopefully improving future coding commits for both myself and the team.
Knowing where to go for answers
The final lesson I learn was knowing where to go for answers. In and of itself, this can mean a lot of different things. It can mean knowing how to search for pieces of code that you need, where to go to find documentation on knew frameworks or libraries, who to ask for help on a specific task, or where when to spend time solving a project yourself rather than depending on others. This is important for ensuring that you are working in an efficient manner so that you are solving tasks that are set for you while also meaning that you are evolving and learning as a software engineer.
An important part of any Software Engineer’s toolkit is to be able to efficiently google to find relevant code that we need. Whether that is to fix a bug or to introduce a new feature, the skill is often the same. Part of this includes also knowing when to simply copy and paste a piece of code and when to dive deeper to understand why the solution works. In some cases, googling code is simply to refresh your memory of how to do something as simple as a loop in a given language or because you forgot a name of a function or a module. In this case, taking code from the internet shouldn’t be a problem as it is simply refresher. In the latter case however, when looking at new code it is often important to understand what it is doing and how. This is not only for security reasons (you don’t want unstable code in your code base) but also to ensure that next time you come across a similar problem or error, you can fix it much quicker and with a better understanding. Otherwise, we would spend all of the time googling and not producing the code ourselves.
The second part of this this is knowing when to try and solve something by yourself versus when to ask someone for help. The first part means that in some cases, a little bit of work on your behalf can get you to a solution reasonably quickly and with a little effort. That means that you don’t have to stop others from doing their own productive work while also ensuring that you are growing and learning as a software engineer. This ensures that you should be able to solve a similar problem in the future and be a more valuable member of your team. Even if you don’t manage to find a solution, having some potential code can help for when you then need to ask someone for help as you can show you at least tried to solve the issue. This can help them get up to speed quickly and ensures they don’t have to waste time on coming up with the same solutions you did. You can also go to someone when you are interacting with a new technology and they have a lot more experience, ensuring they can point you to resources that can help you get started quickly and in the right direction.
The final part of this is then knowing who to go to for efficient problem solving. In some cases this can be a member of the team, or even someone form outside the team, who has worked with a similar technology before. In others, it involves knowing you can ask who may know someone to help, whether that is your manager, your onboarding buddy or your mentor. This means that you need to have a strong and good network of people around you who you can depend on but it also means that you don’t need to know everyone. Otherwise, if you don’t know who to go to, you can be stuck for a very long time which won’t help you progress. You should also not be afraid to ask for this help as most software engineers should understand what it is like to be stuck on a problem and not know where to go.
Thus, knowing where to go for answers can mean different things, whether that is knowing how to correctly google, knowing when to spend time on solving the issue yourself, or when it is time to raise your hand and say you are stuck. Often teams will have a mechanism in place to facilitate this sort of thing, whether that is daily standups or regular team meetings, that will help you to develop this skill. It is also a skill that takes a long time to master and I am certainly still learning as I complete more tasks and understand where the different lines can be drawn.
Conclusions
I have learnt that feedback is important for all aspects of being a software engineer, that clean code is important for creating and producing robust and sustainable products, and that knowing where to go for answers can speed up your development process immeasurably. In most of these cases I still have a lot to learn and take on board, but they are certainly lessons I will continue to take into the future and will certainly help to make me a better Software Engineer or Data Scientist. I hope these are also lessons that others can learn from, and that each of these aspects is important to focus on for continuing to be a better developer. I hope that this will be of benefit to myself for both my career and any team that I will eventually become a part of.
And how they can make you a better developer and data scientist…
Last month I finished my 3-month internship at Amazon in London as a Software Dev Engineer. I learnt a lot during this internship, managed to work on some amazing projects, and worked with some brilliant and talented people. I knew I had a lot to learn in terms of programming, but the internship also taught me that coding isn’t the be all and end all of being a Software Engineer or Data Scientist. To this end, here are the three main lessons I learnt while working for Amazon and why/how they will make me a better software engineer or Data Scientist in the future.
Feedback is important
If you want to become a great software developer/engineer, feedback is incredibly important. This doesn’t just include feedback on your code through processes such as code review, but also in 1 to 1s, team meetings and doc reviews. For this to improve your ability as a software engineer you have to be able to take this feedback on board, learn from it and then make sure you use that going forward.
Among the first places I received feedback, before writing any code at all, were 1-to-1 meetings with my manager, mentor, onboarding buddy, and other team members. This feedback included how I was progressing, what I should be paying attention to, and how I was fitting in with the rest of the team. This meant that I quickly adapt, ask questions, and ensure I was heading in the right direction at all times, and meant that I could onboard to the team and become a useful member much more quickly than I would have done otherwise. Onboarding to a new team is often a big ask where a lot of information has to be taken in; with the guidance of what to focus on, I was able to ensure that I was contributing as fast as possible. This continued throughout the internship where later feedback was on how I was progressing or if there was anything I could improve as to how I was tackling problems.
I was able to receive feedback in a team setting through a process of document review. Since Amazon is a customer-driven and -focused company, I had to ensure that any of my ideas or thoughts as to the tool I was tasked to build would be useful for the customer. In my case, since I was building an internal tool, this meant I had to build something that my team would be able to use. The feedback at this stage, where all the team commented on the features, look, and implementation of the project based on a document I had put together, helped to ensure that the final project would be relevant to them. Without this feedback, the project wouldn’t have met the needs of the customer and it would likely have been discarded after I left! Now though, I was put on the right track to ensure that the team could use in the future.
Finally, I also received feedback on my code through the process of code review. This was the first time anyone was giving me direct feedback on my code, the structure, the implementation and how I was writing it. This was certainly a very nerve wracking process, but it managed to greatly improve the final implementation. Several things were picked up, which I tried my best to implement in the next revision and future commits, and helpful hints were suggested for the future. This has directly helped to improve my code quality, and while there is plenty I have left to improve, I hope to think that this will set me up for more future success.
Feedback then is something that I will continue to seek out in the future wherever it is available and appropriate. While I can learn plenty on my own and build some great projects, at the end of the day someone else may have a different viewpoint or experience that will ultimately lead to better code, a better process, and a better product for the customer.
Clean Code
This lesson leads on from the previous one as the process of code and document review showed that clean code is important for creating a lasting and robust product for the customer. This means that the code should be simply implemented, efficient, and readable/understandable by humans. Clean code should flow in a logical manner to the point that someone new to the could base should be able to relatively easily grasp what is going on and the purpose of a piece of code, without too much prior understanding or documentation.
I am not saying documentation or commenting isn’t important, it is, but the code should be able to speak for itself. I still have a lot to learn in this regard but my main takeaway points from this lesson include:
- Variable and function names should state what they are doing or what they are for. They should be clear and easy to understand. If they are not, then your code can be difficult to read and hard to debug, which, when you have a large code base, can make life 10x more difficult. This includes ensuring the naming convention is consistent throughout your code as otherwise things can become messy and unclear.
- A function should only do one thing. If it is doing more than one thing, it should be broken up so that it is easier to understand and test, ultimately ensuring more robust code. Again, this is useful when you have a very large code base as it means you can easily isolate where a bug has appeared and fix it, without having to dive too deep into the code itself.
- File structure and naming is important. This goes hand in hand with the variable and function naming point, but ensuring that it is easy to find code and that similar code is bundled together is important for debugging and understanding what a code base does. This can get more complicated with a large code base but that just makes it even more important when navigating through a variety of files.
- Finally, although not code itself, commits should be for a specific purpose and small. A large commit covering multiple changes to the code base will make it difficult to see where a bug has been introduced and then how to roll the change back if needed. Separating out commits, and clearly stating their purpose, can help with the long-term maintainability of code.
All of this should also fall in line with accepted conventions of the language or purpose that you are writing in or for. This includes maintaining consistency throughout your code base so there is no confusion, especially when you are working on a project with multiple people involved. All of this will ultimately help with the maintainability and improvability of code not just for yourself, but for your whole team.
While I knew a lot of this before the internship, since no one was reviewing or looking at my code I didn’t know if I was missing something or whether what I was doing was correct. It can often be hard to police yourself after a long day of coding and you are not entirely sure what you are looking for. While this does not mean that you shouldn’t hold yourself to a high standard, or that you should depend on others to solve your code, it means that a good team can ensure high standards are kept and that you are constantly learning from each other. The code review process has helped me learn a lot and hopefully improved my code readability and purpose, hopefully improving future coding commits for both myself and the team.
Knowing where to go for answers
The final lesson I learn was knowing where to go for answers. In and of itself, this can mean a lot of different things. It can mean knowing how to search for pieces of code that you need, where to go to find documentation on knew frameworks or libraries, who to ask for help on a specific task, or where when to spend time solving a project yourself rather than depending on others. This is important for ensuring that you are working in an efficient manner so that you are solving tasks that are set for you while also meaning that you are evolving and learning as a software engineer.
An important part of any Software Engineer’s toolkit is to be able to efficiently google to find relevant code that we need. Whether that is to fix a bug or to introduce a new feature, the skill is often the same. Part of this includes also knowing when to simply copy and paste a piece of code and when to dive deeper to understand why the solution works. In some cases, googling code is simply to refresh your memory of how to do something as simple as a loop in a given language or because you forgot a name of a function or a module. In this case, taking code from the internet shouldn’t be a problem as it is simply refresher. In the latter case however, when looking at new code it is often important to understand what it is doing and how. This is not only for security reasons (you don’t want unstable code in your code base) but also to ensure that next time you come across a similar problem or error, you can fix it much quicker and with a better understanding. Otherwise, we would spend all of the time googling and not producing the code ourselves.
The second part of this this is knowing when to try and solve something by yourself versus when to ask someone for help. The first part means that in some cases, a little bit of work on your behalf can get you to a solution reasonably quickly and with a little effort. That means that you don’t have to stop others from doing their own productive work while also ensuring that you are growing and learning as a software engineer. This ensures that you should be able to solve a similar problem in the future and be a more valuable member of your team. Even if you don’t manage to find a solution, having some potential code can help for when you then need to ask someone for help as you can show you at least tried to solve the issue. This can help them get up to speed quickly and ensures they don’t have to waste time on coming up with the same solutions you did. You can also go to someone when you are interacting with a new technology and they have a lot more experience, ensuring they can point you to resources that can help you get started quickly and in the right direction.
The final part of this is then knowing who to go to for efficient problem solving. In some cases this can be a member of the team, or even someone form outside the team, who has worked with a similar technology before. In others, it involves knowing you can ask who may know someone to help, whether that is your manager, your onboarding buddy or your mentor. This means that you need to have a strong and good network of people around you who you can depend on but it also means that you don’t need to know everyone. Otherwise, if you don’t know who to go to, you can be stuck for a very long time which won’t help you progress. You should also not be afraid to ask for this help as most software engineers should understand what it is like to be stuck on a problem and not know where to go.
Thus, knowing where to go for answers can mean different things, whether that is knowing how to correctly google, knowing when to spend time on solving the issue yourself, or when it is time to raise your hand and say you are stuck. Often teams will have a mechanism in place to facilitate this sort of thing, whether that is daily standups or regular team meetings, that will help you to develop this skill. It is also a skill that takes a long time to master and I am certainly still learning as I complete more tasks and understand where the different lines can be drawn.
Conclusions
I have learnt that feedback is important for all aspects of being a software engineer, that clean code is important for creating and producing robust and sustainable products, and that knowing where to go for answers can speed up your development process immeasurably. In most of these cases I still have a lot to learn and take on board, but they are certainly lessons I will continue to take into the future and will certainly help to make me a better Software Engineer or Data Scientist. I hope these are also lessons that others can learn from, and that each of these aspects is important to focus on for continuing to be a better developer. I hope that this will be of benefit to myself for both my career and any team that I will eventually become a part of.