Did you ever consider becoming a teacher of software engineers? I’m assuming many of us have not – simply because it’s an uncommon career path, and teaching rarely feels likely to be lucrative, compared to hands-on building (we previously covered Common engineering career paths as Big Tech and scaleups). But teaching software engineers is an interesting challenge for a few reasons:

• Many engineers are good at learning by themselves, so may initially assume there’s little value in being taught by others

• But, great teachers make a real difference in getting up to speed, including for software engineers

• There’s demand at tech companies for innovative teaching approaches and new technologies for devs

To discover what being a full-time trainer of tech professionals is really like, I turned to software developer turned full-time trainer, Reuven M. Lerner.

Reuven worked as a developer for 15 years, and for the past decade and a half he's been a full-time instructor. He teaches Python, Pandas, and Git for a range of companies, including Apple, IBM, and Cisco. He does both corporate training, as well as online Python courses for individuals.

Today, Reuven takes us behind the scenes of technical training, covering:

1. Coding vs teaching it. You optimize software when coding, whereas with training you optimize how to best teach the writing of software.

2. Is training helpful? Many software engineers learn by themselves, and it can be hard to get dedicated time at work for training. But group courses boost communication across tech teams.

3. What makes effective teaching? Reuven’s thoughts, including on using interactive notebooks over slides, exercises above theory, and lots of pair programming.

4. Day to day. Teaching learners is just one part of being a trainer: sales, marketing, customer support, and continuous learning are also key.

5. Business of teaching. To work as a career, teaching must be a solid business. Reuven shares how he runs his operation, from closing new clients and educating decision makers, to collecting payment.

6. Advice for future trainers. Get comfortable with public speaking, go deep into a technology, don’t shy away from niches, and more.

With that, it’s over to Reuven:

When I got my computer science degree 30 years ago, I knew what my career would look like: I would develop software, eventually move up to manage other people, or maybe start my own business. Indeed, after writing software for Hewlett Packard and Time Warner’s “Pathfinder” website, I opened my own consulting shop, writing Web applications and running Linux-based servers.

Fast forward to today, and my career looks very different. I’m still self employed, but instead of developing software, I’m a full-time trainer in Python and Pandas. I teach at big companies like Apple, Arm, Cisco, and Western Digital, and at startups and financial institutions. I offer more than 30 courses, ranging from “Python for non-programmers,” and “Data analysis with Pandas,” to advanced practice workshops. Between these, I have a growing business of online courses and newsletters for people without access to company training programs.

I feel like I have the best of all worlds: I help people improve their careers, learn new technologies, and interact with smart people all over the world. Plus, I set my own schedule far in advance, have only a handful of meetings a month, spend time with my family, and get paid well — better, in fact, than many developers. I’ve never earned more, and I’ve never enjoyed my work more.

In this post, I introduce the world of tech training. I reveal how it operates, what I’ve found does (and doesn’t) work for training, how I run my business, and how you can explore the world of training.

How I became a full-time trainer

When I started consulting in 1995, I positioned myself as a coder and Linux expert. But some companies asked me not to develop software for them, but to teach their people how to do it. That was my first taste of training and I rather liked it, but saw it as just one part of my consultancy work. Indeed, I rarely spent more than 20 percent of my time on training.

In 2003, I started a PhD program, continuing to consult part-time in order to support my family. While working on my dissertation, a colleague suggested I concentrate on training, and offered to connect me with a company. I said yes – a decision which changed my career.

This training company marketed my Python courses, and filled up my calendar with training sessions. Soon, my schedule was full several months in advance. As convenient as it was to work with them, I also knew that they were keeping half the income.

When I finished my PhD in 2014 (after 11 years!) I left the training company and rebranded myself as a trainer. I’ve now been teaching Python, Pandas, and Git full time for around 15 years and absolutely love it.

My focus on Python turned out to be fortunate because it is used just about everywhere. Even hardware companies that mainly work in C, like Apple, Arm, and Western Digital, use Python on all sorts of internal testing and analysis projects. Financial institutions are moving to Python instead of Excel, and want help in making the switch. Companies doing numerical analysis with Matlab are tiring of the high per-seat licensing cost, and are moving to Python – and need help easing employees into a new environment.

I mostly teach people who are highly schooled and very smart, many of whom have engineering degrees and at least some experience of coding. In theory, their employer could buy them books or video courses, and ask them to learn Python solo. In practice, we all know this doesn’t work; we’re often too busy to use such materials. A timeboxed course, delivered in person and with everyone in the same place is the fastest option with the best results, and it helps establish best practices, instead of just learning the syntax.

1. Coding vs teaching it

How is my life and work different as a trainer, than as a coder? Some of the biggest differences:

As a trainer, my goals are fundamentally different from a full-time software engineer’s. A coder’s goal is to get new or improved functionality out the door. In contrast, my job is to help someone do their job better and faster by writing more idiomatic, maintainable, and efficient code quicker.

I spend much of my time thinking about code. However, I do not do this in the same way I did when working on software projects. I’m not trying to optimize software; I’m trying to optimize learning about writing software. I always seek to simplify and improve my explanations, and find stories, metaphors, and examples that improve my teaching. I’m constantly trying to understand how certain packages and techniques work, so I can explain and illustrate them better to students.

In many ways, I’m like a stand-up comedian. I teach so often, so I see which examples, explanations and exercises work, and which don’t. Just as a comedian changes their jokes from show to show and iterates repeatedly until they find what works, I’m constantly experimenting with what and how I teach, trying to find the optimal way to get information across.

I particularly enjoy using stories in my teaching. Good stories reinforce the ideas being taught, and also enliven classes on potentially dry, abstract topics.

Often, these stories come from personal experience. One recent example: Meta banned me from advertising my courses and newsletters on their platforms, apparently because they believe I was illegally trading in exotic animals (pythons and pandas – the irony!) This event was widely discussed on programming forums like Hacker News.

This was as bizarre and frustrating as it was amusing, but you can be sure I’ll tell this story every time I teach a course on machine learning, and the need to test models before deploying them to production.

When I was doing software projects, it was hard to set my schedule in advance. Typically, someone needs a software project done now, or they don’t want it at all. Talking to someone about a project six months hence is generally a non-starter.

By contrast, there’s almost never a training emergency. As such, training can be scheduled two, four, or even six months in advance. At the time of writing, I already have courses in my schedule for January 2025, and I’m talking to clients about scheduling beyond that.

This ability to plan ahead has improved my personal life and my business. I can now schedule vacations knowing when I will have training gigs. I also have a much better sense of how much I’ll earn in a given month; a much better situation than the feast-or-famine roller coaster of my first years of freelancing.

Shock news: training can pay far better than coding! On the topic of money, here’s a lesser-known detail about training I’ve experienced: It pays better, often far better, than coding because:

• If you help 20 developers to become 10 percent more effective, that’s worth a lot of money. So it’s absolutely worthwhile for a company to invest in good, effective training.

• The budget doesn’t come from R&D. Rather, it comes from HR, or from a special training budget. Whereas a company might balk at paying thousands of dollars per day for a developer, this is considered to be a normal rate for training services!

• Training is usually done through companies with overheads like offices and employees in sales/marketing. A freelancer doesn’t have these costs. Companies will pay roughly the same for training regardless of the training vendor’s size and overheads. I’m a one-person company based in a home office, so I can basically pocket what other companies spend on their costs!

Hardly any meetings. This is another major difference between doing coding and providing training. I’ll typically speak with a new client two or three times before the first class takes place, and maybe once after the first session to wrap things up. But if they ask me to teach again, we just exchange some email, mainly about dates. If I have 4-5 meetings a month, that’s a lot – which means I can spend more time teaching and developing new course materials.

I do miss software projects. I’ve experienced first-hand that there’s nothing like pushing technological boundaries and launching a product, knowing that people around the world are using and enjoying it. And there’s a definite limit to the size and scope of things I can do on my own, rather than in a larger team.

That said, most projects I worked on weren’t pushing boundaries. And while many were exciting, completing them didn’t give me the same sense of purpose and fulfillment I get from teaching. Besides, now I get to write whatever code I want – and there is definitely code to write, whether as part of my courses or running the backend of my online store and newsletters.

My online store’s tech stack combines:

• Podia: a SaaS where my video courses live

• WooCommerce: an e-commerce SaaS handling payment and subscriptions

• Drip: email marketing SaaS, used for two of my newsletters and marketing blasts. I use a fair amount of custom programming (“workflows”) here

• Ghost: a CRM and email service used for Bamboo Weekly

• GitHub: I create a new repo for each course I teach

• Flask: a Python framework I run on a standalone server for one-time coupon codes

• Discord: used for discussion among my members.

• Zapier: an integrations platform I use to connect these systems. For example, someone subscribing to my Python+Data product is enrolled in all my courses, added to my Better Developers list, and is added to the appropriate GitHub repos.

• Custom Python scripts: These help me set up and tear down environments when I give corporate training. Each class gets a new GitHub repo, as well as its own set of Jupyter notebooks. This, along with the “gitautopush” package, lets me work on my own computer and share the course contents with participants in a given course in near-real time.

Do I plan to consolidate these into a smaller number of services? Yes, absolutely. But one person can only do so much in a day. Between teaching, writing three weekly newsletters, responding to learners and researching new topics, I don’t have much time for major technological shifts. But I do have a roadmap; for example, I’ll soon move discussions from Podia to Discord, which seems to foster a greater sense of community.

2. Is training helpful?

I once met someone with a background in engineering and education. I told him what I did and he replied:

“Oh, so you’re an entertainer? Because we both know that you’re not giving any real educational value.” 

This comment hurt. Still, I’m sure many developers who attend my classes also believe they could learn the same material as quickly and as well by themselves, and that my courses are a nice vacation from “real” work. I understand this, but here’s what I’ve learned from years of teaching.

Most people benefit from having someone explain things, including developers who could learn on their own! After I gave a talk at PyCon US this year, a developer told me my presentation answered questions they didn’t even know they wanted to ask. 

I spend a lot of time thinking about the questions people might have beyond simple use cases and syntax, and I integrate them into my teaching. People could get these insights themselves, but it would take longer and not necessarily be contextualized appropriately.

Pressure at work stops many developers learning new things by themselves. One client of mine decided to save money and bought my video courses for their staff. When I came in to do a live Q&A based on the videos, the only person who had really watched them had red eyes, because he had finished at 2:30 a.m. In the end, we returned to in-person lectures.

Learning the nuances of a language is faster with an instructor. Python is a good example; I’m often told this language has such simple syntax that a course isn’t really needed, and it is true the language is pretty simple, with just a few core data structures. So how long can it really take for an engineer to figure it alone? 

This argument is similar to saying chemistry is simple because there are only 118 chemical elements in the universe. Learning the nuances, use cases, limitations, and conventions takes time. This is as true for Python as for chemistry. Going beyond basic syntax is usually faster and more memorable with an instructor.

For example, when I teach Python I dive into the details of the += operator. I explain that even though it does what you expect, one should be careful when using it to concatenate strings. If preserving memory is important, then you should always use a combination of a list and the str.join method to conserve memory. I talk about the different ways to iterate over a dictionary, and why using the dict.keys method is almost always a bad idea. We discuss the difference between the “__str__” and “__repr__” methods, and when to use each (and why I think it’s OK to only define “__repr__”).

Having everyone take a course can improve workplace communication. If people learn solo they’ll understand different things, and choose their own styles/conventions. Giving the same training across a company ensures everyone has the same (or similar) skill levels and understanding, making communication easier within and across teams.

Hands-on exercises are the most efficient way I know how to teach. I’ve fine-tuned coding exercises over years to illuminate certain techniques, syntax, and conventions. I call these exercises “controlled frustration.” The goal is to solve a problem without a manager or deadlines adding to stress levels. 

Learning from other people's mistakes is a great way to learn and in a group setting, this is much easier. As important as it is for students to do exercises, it’s also important to review the exercises together and learn from each other’s buggy code. Also, when I demonstrate how to solve a problem, I’m modeling a process they can apply to their jobs.

Companies rarely give people time to pick up new techniques and technologies. It is true there are plenty of developers who can learn on their own. The trouble is finding dedicated time to focus on learning. I’ve found people often enjoy being in advanced classes – especially exercise-only classes – where they can solve interesting problems they might not have the opportunity to do at work.

As a manager, when does it make sense to consider bringing in a trainer? If your team is adopting a new technology, or if you’re all a little shaky with using it, or you observe devs always going to ChatGPT (or StackOverflow – if you still use it!) to solve problems, then you might want to consider bringing in an instructor. A good instructor with plenty of experience can anticipate which mental models help engineers, and has exercises to take their understanding to the next level.

Also, training empowers members of staff; improving their communication skills and distributing knowledge across organizations. Six months after I taught a Git course at one company, an engineer told me he was now the Git expert in his group, and no longer had to guess what to do when they got in trouble. Not only did he feel great about himself and this new knowledge, but his group benefited from having a local expert.

3. What makes effective teaching?...