Talking Tech With Amazon's Jamarr Lampart

Want my Forbes content and the latest early-stage tech news delivered to your inbox? Subscribe to my mailing list, Founder to Founder: f2f.substack.com

Jamarr studied at MIT, where he received his Bachelor's degree in Computer Science. Afterward, he joined Amazon full time as a software engineer on the Visual Search team, where he interned the summer preceding his senior year. At Amazon, he works on the Augmented Reality product, 'ARView', as an Android developer.

Frederick Daso: What are the significant differences between writing code in school at MIT and now at Amazon?

Jamarr Lampart: MIT, being an educational institution, optimizes for students' learning and growth in skills. Amazon, being a public company, optimizes for profits (and customer satisfaction). The four years I spent at MIT was centered around learning fundamental concepts governing the field of Computer Science, and by extension, software engineering. Every semester I took courses meant to develop my expertise in different topics: designing algorithms, writing mathematical proofs, building websites, and more. While these courses were excellent at challenging my ability to write clean, efficient code, they were even better suited at developing my ability to problem-solve. Code was simply the language used to translate the solution to a complex problem.

Amazon, by contrast, expects one to produce code with an emphasis on satisfying the customer more-so than a learning experience for the individual contributor (IC). Depending on the team and manager, ICs may grow their skills as a by-product of satisfying the customer. Still, the primary objective is to write well-functioning code with minimal bugs. Writing code in an academic setting tends to have much less focus on the cleanliness, in terms of proper variable names, proper documentation, etc. In industry, the code-base is typically much larger and so requires more developers to contribute to it. ICs are expected then to write high-functioning code that is easy to read and extendable. I personally found that any bad habits I picked up in college when writing code to solve problems were quickly rectified after joining Amazon. My team had a strict structure for how code should be written, documented, and reviewed, which I was expected to follow.

Daso: How do you decide which company to join (in your case, Amazon)?

Lampart: Depending on what stage of life I am in, this changes a lot. As a senior in college, I was optimizing for intellectual growth, impact, and harmony with the team. I had interned with my current team in 2016 the summer before my senior year, so it was easy for me to accept the return offer given my experience with them. I knew that there would be plenty of opportunities for me to grow career-wise. I had already established a positive relationship with the managers and other ICs on my team.

Today, I am optimizing for different things. I do not necessarily want to be "the best software engineer that I can be" relative to a few years ago, but I do still desire to be an excellent software engineer. What that means is, I am increasingly interested in incorporating a more "free-agent" aspect to my career. I am not keen on joining a startup but would be very eager to start my own. However, there are a few factors that still need to be addressed before finalizing that decision. Ultimately, I decide where to take my career based on team dynamics, growth in skills, financial considerations, and freedom to work with minimal bureaucratic obstruction.

Daso: As a software engineer, how do best practices in producing production-level code change over time?

Lampart: In many ways, this depends entirely on the language or technology being used. For some languages, nothing changes much over time for a few reasons. The language may be sufficient as is. Another reason could be that a dwindling developer base has led to a lack of updating of the standards of the language. I primarily code in Java and work on an Android application using Google's ARCore software development kit (SDK). Unfortunately (or fortunately) for me, each of those three things change quite a bit over time. Java, as a coding language, gets updated routinely ever few years, introducing new concepts such as streams, closures, and other concepts.

It is difficult to learn and actively implement new changes without a strong need for that change. However, without being familiar with the concept, it may make reading other people's code more difficult, especially if they opted to use those newer language additions. The same applies to the Android ecosystem, which is infamously very fragmented. Google provides the software, but each manufacturer has some level of jurisdiction over how it behaves on their device. I have run into numerous issues at Amazon that was "expected" Android behavior on Pixel phones vary quite a bit from that on Samsung devices.

These have sometimes led to the application itself crashing for our customers, which are especially challenging to address. Due to this inconsistency, it is challenging to keep up with some best practices for Android, but I try my best. Google's ARCore SDK is very new, so there are no "best practices" necessarily at this moment for how best to use it. In a more general-sense, best practices for producing production-level code can either not change at all for decades or change drastically every few years, depending on the language and technologies being used.

Daso: How best should a junior SWE develop into a senior SWE?

Lampart: A lot of the growth SWEs experience comes down to the experience and complexity of the code or projects they work on. Experience teaches you how best to plan for unexpected changes, both in your team, customer base, and the industry at large. The complexity of the code you write challenges you to come up with new, smart ways to solve challenging tasks. The complexity of the projects you work on pushes your ability to deliver features with minimal delays and bugs. Also, you grow in designing more complex code architectures to simplify the logic you will implement. You must read and write a lot of code to build experience, but it needs to be focused. If you are reading and writing the same routine code every day, such as with legacy systems, you will likely not grow much in your role. Seek out newer domains and different aspects of each system (networking, scaling, caching, memory management, etc.) to better understand how everything comes together.

Daso: Do you think SWE internships are representative of day-to-day life at a tech company?

Lampart: Yes, very much so. All of my past SWE internships mirrored what I saw my coworkers doing, or in the case of Amazon, what I did after joining full-time. Your manager will typically be more lenient with you as an intern, given your lack of overall experience but also unfamiliarity with the code-base. As a full-time SWE, you are given an undisclosed "grace" period with which you can take your time and build familiarity with the code-base and systems used by your team. During this time, you will be judged much less strictly by your peers. However, you will see how quickly you catch up to speed with everyone else. Given that most SWE internships last 8 - 12 weeks, this is not enough time to build familiarity. Still, your tasks are pretty much unchanged relative to your coworkers. 

Daso: Does pursuing passion projects outside of work help keep your skills sharp and opportunities open?

Lampart: Yes and no. If your passion projects relate to what you do at work, yes. If it is in a completely different area, it depends on what you are optimizing for. If you write logistic regression models in your free time with no professional or academic experience in statistics, do not expect to be offered machine learning opportunities anytime soon. Employers are doubtful to take a risk in hiring you, especially if the market is scorching for those skills. You would also not likely keep those skills sharp since most of your working hours are spent at work writing code in a completely different area.

Furthermore, passion projects do not force you to adhere to best practices and standards the way your coworkers who have to review and extend your code would. Some people are disciplined enough to adhere to the same strict coding regimen imposed by their workplace. Still, most passion projects that do not have a long term focus from the outset of development tend to be sloppy in terms of adhering to best practices in the industry. I would almost always suggest working on passion projects simply because you are passionate about the topic itself. 

Want my Forbes content and the latest early-stage tech news delivered to your inbox? Subscribe to my mailing list, Founder to Founder: f2f.substack.com

If you enjoyed this article, feel free to check out my other work on LinkedIn and my personal website, frederickdaso.com. Follow me on Twitter @fredsoda, on Medium @fredsoda, and on Instagram @fred_soda.