How to learn AI as a software engineer

I had the opportunity to host a couple “Birds of a Feather” discussions at Amazon’s conference for Software Developers with the topic “How to learn AI as a software engineer”. Birds of a Feather is a type of informal gathering in the tech community - it is for people who are all interested in discussing a topic together without a set agenda. I thought this would be an interesting topic for a few reasons

One reason might feel very superficially obvious - AI is a hot topic right now, and many software engineers are eager to use it and learn it. The deeper part of this one is that because it is such a hot topic and everyone is talking about it, the barrier to asking a question when you don’t understand something or want to learn more can feel bigger than it needs to be. There’s so much conversation that it’s easy for people to feel like it has already passed them by. I hoped engineers would sit down at my table and just ask whatever they were curious about. Another reason is based on my own learning experience - AI was a once focus of mine for graduate work and it has become very relevant to my current work again, so I personally make it a habit to learn something every day in this space. I felt I could share at a minimum some current resources and tips, and break down some of the perceived barriers. Lastly, I really wanted to hear what software engineers want to learn and are curious about. It is invaluable to understand how different people view topics and what they want to learn about so we can make sure to create paths such that everyone can have the opportunity to explore and be successful at it.

I’m sharing a few of the top questions that came up in the discussions.

Question 1: I’m not working on this right now as part of my team work, how can I learn anyway?

A big part of the engineering job at any level is to reserve time for learning, and sometimes that’s learning something that you’re not directly using for your work yet. There’s a couple approaches here that I find helpful. First, talk with your manager about your learning time at work - it’s possible there’s buffer budgeted for this, or that you can get it planned into your sprint. Some teams or orgs will do something like set aside a Friday every couple weeks for innovation or tinkering, or another variation on that. The main point, is make it part of your normal work week. Then, as your own choice, you can dedicate time outside of work to whatever you want, including additional learning.

Dedicating time to reading can make a big difference, and/or tinkering with a side project. If your goal is learning how to incorporate an LLM into an application, go ahead and set up a project with your favorite option to try it out. If you want to just become a user, try out Code Whisperer from AWS or GitHub’s Copilot in your IDE. Try out Dall-e-3 and go wild. I definitely did that with a fantastical cartoon depiction of AI, learning, compute, and some other over-the-top prompts for the image in the banner of this post. I figured I might as well if I am talking about AI!

Follow-up: What if I definitely want to use it for my regular projects at work?

If your goal is to work on a team that lets you use these skills, your options could be 1) see if your team might actually have something on the road map or a good problem that would be well-solved by applying something you’re learning about, or 2) try to find a new team or job that has what you want to grow your skills for career. This advice is pretty general for any technology or skill you’re interested in; it still works for this as well.

Something to keep in mind if you’re trying to find a way to use GenAI or ML - is there another way to do this that would be easier, or better in some way? Make sure to avoid the tempting trap of doing it just for the sake of doing it. In that case an experimental or side project might be a better option.

Question 2: What resources should I use? How do I pick which ones to look at, when there are so many?

The overwhelming amount of material can make it feel hard to figure out what to even look at. Ask yourself, what you want to really learn about. Do you just generally want to have an idea on the latest advancements, to stay a bit up to speed on context, but not care so much about going into technical depth? There’s a lot of articles and papers, as well as software and tools you can explore. Just regular exposure to anything on AI is going to over time prime your brain for it. Sometimes subscribing to a publication can be really worth it, there’s also a good amount of free articles out there. I recommend articles over papers unless you are going deep into a particular topic. As to what to read, I will leave that to your and your searching capabilities. As an example, I do like following the topics of LLMs doing math, starting with this one: Google DeepMind used a large language model to solve an unsolved math problem, and recently Large language models can do jaw-dropping things. But nobody knows exactly why.. Find what intrigues you and follow it.

If you’re interested in a particular aspect, for example if you want to be able to know what working on a machine learning model is like, there’s a lot of great (and some free) resources out there. For example MLU from Amazon, or this Google Machine Learning Crash Course, or search for one of many lecture series on YouTube. This can get you a good hands on feel, as well as give avenues for depth.

Once you know you want to focus on something in particular, go deep if you like!

Question 3: What will the SDE 1 role look like in the future? Will it exist?

Engineers who asked this cited given things like code generation, do we still need beginner level engineers?

Obviously I don’t know the future. That said, I can give my take on this based on previous experience of how the industry changes with new developments.

Firstly, I’m pretty confident we will still need software engineers in the foreseeable future. As a software engineer (or any career with an associated skill set that requires learning and discipline over time), you have to start somewhere. You don’t magically become experienced - or start as a senior level engineer because a part of the job changed. It’s very possible some of the work at the start your career might look a little different than it does now if we have built in new abstractions and tools we didn’t have before. At the discussion, I asked the group to raise their hands if they coded assembly as an SDE 1, and no one did. I asked if they had to implement a standard sorting algorithm - again all no, that was just for learning. There are many things we don’t actually do for our jobs anymore that we learn to build a solid foundation. Now, they are encapsulated in components or libraries we can integrate. We understand them, know how they work, know how to use them, but no longer have to build them from scratch. I’m imagining we will have some new abstractions around what kind of code we don’t write anymore one day, but that we are still designing software and writing some code to bring that in.

All that said, I am hopeful one day we will have AI code assistants that don’t hallucinate methods on classes or objects.