Ah, Git. It’s one of the best and most important tools I use as a software developer. Git is everything I want in a version-control system: It’s fast. It lets me collaborate. I can work without an Internet connection. I can branch and merge easily, using a variety of techniques. I can take a personal project and turn it into a large, collaborative one with minimal effort. And it’s cross platform, meaning that I know my clients and colleagues will be able to use it.
So, what’s the problem? Git’s learning curve is extremely steep. Until you understand what Git is doing, and how it works, you cannot use it effectively. Moreover, until you understand what Git is doing, you will likely be puzzled and frustrated by its commands, messages, and documentation.
I’m thus delighted to unveil my latest online course: Understanding and mastering Git. This course, which I have taught to numerous companies all around the world for more than a decade, includes:
If you have been frustrated by Git, or consider the commands you’ve been using to be a form of black magic, then this course is for you. It walks you through Git’s commands, objects, and methods for collaboration.
This course has been battle-tested for a decade at some of the world’s best-known companies. If you want to get the most out of Git, I’m sure that my course will help. And if it doesn’t? E-mail me, and I’ll give you a 100% refund.
Don’t let Git frustrate you any more. Understand it. Master it. Tame it. Learn from my “Understanding and mastering Git” course, today:
Not sure if this course is for you? That’s fine: You can preview a number of the course videos for free from the course sales page.
Also: If you’re a student or pensioner, then you qualify for a discount on the course. Just e-mail me, and I’ll send you a special discount code.
You can and should learn Git, and I want to help you to learn it. Try my course, and discover why so many software engineers won’t even think about using something else.
Back in July, I gave three live, online courses: Object-oriented Python, functional Python, and Python decorators. I have long found that all three subjects are misunderstood by many Python developers, and I wanted to help people to understand how and when to use each one.
I’m pleased to announce that recordings from all three courses are now available for sale.
These are the same courses that I give all over the world to engineers at such companies as Apple, Cisco, Ericsson, IBM, VMWare, and Western Digital.
If you have ever wanted to level up your understanding of these topics, I think that my courses will really help you out. Not only do I explain what’s going on, but I also ask you to do exercises to help cement these ideas in your mind. Of course, I go over every exercise as well, and provide the Jupyter notebooks and files that I created when doing so.
Want to buy learn more? Just click on the appropriate link for each one:
If you’re a student, then e-mail me for a discount code good on any (or all!) of these courses.
If you have any questions about the courses, just reply to this e-mail, or contact me at email@example.com.
I’ll be offering some more live courses later this month (October); I’ll be posting dates and topics on Monday of next week, so stay tuned for even more Python goodness!
I spend most of my time nowadays going to high-tech companies and training programmers in new languages and techniques. Actually, many of the things I teach them aren’t really new; rather, they’re new to the participants in my training. Python has been around for 25 years, but for my students, it’s new, and even a bit exciting.
I suggested the first solution that came to mind: Regular expressions.
Regular expressions are a lifesaver for anyone who works with text. We can use them to search for patterns in files, in network data, and in databases. We can use them to search and replace. To handle protocols that have changed ever so slightly from version to version. To handle human input, which is always messier than what we get from other computers.
Regular expressions are one of the most critical tools I have in my programming toolbox. I use them at least a few times each day, and sometimes even dozens of times in a given day.
So, why don’t all developers know and use regular expressions? Quite simply, because the learning curve is so steep. Regexps, as they’re also known, are terse and cryptic. Changing one character can have a profound impact on what text a regexp matches, as well as its performance. Knowing which character to insert where, and how to build up your regexps, is a skill that takes time to learn and hone.
Many developers say, “If I have a problem that involves regular expressions, I’ll just go to Stack Overflow, where my problem has likely been addressed already.” And in many cases, they’re right.
But by that logic, I shouldn’t learn any French before I go to France, because I can always use a phrasebook. Sure, I could work that way — but it’s far less efficient, and I’ll miss many opportunities that would come my way if I knew French.
Moreover, relying on Stack Overflow means that you never get a full picture of what you can really do with regular expressions. You get specific answers, but you don’t have a fully formed mental model of what they are and how they work.
But wait, it gets worse: If you’re under the gun, trying to get something done for your manager or a big client, you can’t spend time searching through Stack Overflow. You need to bring your best game to the table, demonstrating fluency in regular expressions. Without that fluency, you’ll take longer to solve the problem — and possibly, not manage to solve it at all.
Believe me, I understand — my first attempt at learning regular expressions was a complete failure. I read about them in the Emacs manual, and thought to myself, “What could this seemingly random collection of characters really do for me?” I ignored them for a few more years, until I started to program in Perl — a language that more or less expected you to use regexps.
So I spent some time learning regexp syntax. The more I used them, the more opportunities I found to use them. And the more I found that they made my life easier, better, and more convenient. I was able to solve problems that others couldn’t — or even if they could, they took much longer than I did. Suddenly, processing text was a breeze.
I was so excited by what I had learned that when I started to teach advanced programming courses, I added regexps to the syllabus. I figured that I could figure out a way to make regexps understandable in an hour or two.
But boy, was I wrong: If there’s something that’s hard for programmers to learn, it’s regular expressions. I’ve thus created a two-day course for people who want to learn regular expressions. I not only introduce the syntax, but I have them practice, practice, and practice some more. I give them situations and tasks, and their job is to come up with a regexp that will solve the problem I’ve given them. We discuss different solutions, and the way that different languages might go about solving the problem.
After lots of practice, my students not only know regexp syntax — they know when to use it, and how to use it. They’re more efficient and valuable employees. They become the person to whom people can turn with tricky text-processing problems. And when the boss is pressuring them for a
After you go through all 50 exercises, I’m sure that you’ll be a master of regular expressions. It’ll be tough going, but the point is to sweat a bit working on the exercises, so that you can worry a lot less when you’re at work. I call this “controlled frustration” — better to get frustrated working on exercises, than when the boss is demanding that you get something done right away.
If you have always shied away from learning regular expressions, or want to harness their power, Practice Makes Regexp is what you have been looking for. It’s not a tutorial, but it will help you to understand and internalize regexps, helping you to master a technology that frustrates many people.
To celebrate this launch, I’m offering a discount of 10%. Just use the “regexplaunch” offer code, and take 10% off of any of the packages — the book, the developer package (which includes the solutions in separate program files, as well as the 300+ slides from the two-day regexp course I give at Fortune 100 companies), or the consultant package (which includes the screencasts, as well as what’s in the developer package).
I’m very excited by this book. I think that it’ll really help a lot of people to understand and use regular expressions. And I hope that you’ll find it makes you a more valuable programmer, with an especially useful tool in your toolbox.
I was recently interviewed by Dave Rael for the “Developer on Fire” podcast. That episode has now been released, at http://developeronfire.com/Podcast/Episodes/reuven-lerner-sharing-insight. Enjoy!
What, exactly, do I do for a living?
Yes, I’m a programmer — or as I’m supposed to say nowadays, a “full-stack Web developer.” And yes, I’m a lead developer/CTO. And yes, I’m a writer, with two ebooks written (about Python and visiting China), two more on the way, and my monthly Linux Journal column now in its 20th (!) year.
But over the last few years, another role has increasingly dominated the others: Much of my time is now spent as a technical trainer, teaching a variety of open-source technologies — Python, Ruby, Git, and PostgreSQL — to companies around the world.
Some software developers believe that training is less demanding, less fulfilling, or even less lucrative than creating software. And for some of them, that might well be true.
I have personally found training to be no less demanding than developing software — but I have also found that it is extremely fulfilling, and that it does a more-than-adequate job of paying the bills. We all know that high-tech companies are desperately looking for high-quality developers; when I do my job right, I provide them with such developers, ready to use the latest technologies to solve problems more efficiently and reliably than would otherwise have been possible.
The good news is that my training business is going quite well; I’m now booked solid for several months in advance, and I get to work with some great companies and very bright engineers. Part of my motivation for writing ebooks is now to reach the people whom I cannot possibly teach in person.
Being a trainer requires a number of skills beyond knowing how to program: You also need to know how to organize a syllabus, prepare exercises, prepare slides and printed materials, speak in front of a group, and answer questions. Beyond that, you also need to understand the business side of training — what are companies looking for, how do you approach them, how much do you charge them, and how can you grow your training business when companies are satisfied with your work. These skills, like many others, take time develop, and everyone has their own strengths and weaknesses. But I believe that if you’re willing to put in the effort, then you can learn how to become a technical trainer, and have the same sense of job satisfaction that I do.
If you are such a person, interested in offering technical training — on any subject, not just the technologies in which I specialize — then I invite you to consider joining my coaching program for technical trainers. This isn’t a course; it’s a personalized program that will help you to improve, month by month, in all of the ways that you need to become successful. You’ll have access not just to me, but to other trainers with varying levels of experience, who will provide you with feedback — just as I hope you’ll help them. The program is still in its infancy, but I believe that I’ve put together a combination of resources that can help everyone to become a trainer.
I’m launching the coaching program in two weeks, on October 1st, 2015. There aren’t any formal start of finish times; if you want to start later, then that’s fine, as well. My hope is that you’ll stay in the program for as long as you need to improve, getting feedback from me and others. I also hope and expect that the program will more than pay for itself.
I’ll be holding a free Webinar on the subject of technical training on October 14th, at which I’ll also be taking questions from anyone who might be new to this field, or be curious about what it involves. I invite you to read more about my coaching program, to contact me if you have any questions about it, and to register for the Webinar that I’ll be holding next month!
If you’re like me, you love to learn. And in our industry, a primary way of learning involves attending conferences.
However, if you’re like me, you never have the time to actually attend them. (In my case, the fact that I live far away from where many conferences take place is an additional hindrance.)
Fortunately, a very large number of talks at modern conferences are recorded. This means that even if you didn’t attend a conference, you can still enjoy (and learn from) the talks that were there.
However, this leads to a new and different problem: There are too many talks for any one person to watch. How can you find things that are interesting and relevant?
My latest side project aims to solve this problem, at least in part: DailyTechVideo.com offers, as its name implies, a high-quality, thought-provoking talk about technology each day. To date, almost all of the talks reflect the technologies that are of interest to me, which typically means that they are open source programming languages, databases, or Web application frameworks. But I have tried to include conference videos that have provoked and prodded my thinking, and which are likely to be helpful for other professionals in the computer industry. Moreover, I’m hoping to receive suggestions from people who have seen interesting videos in fields with which I’m less familiar (e.g., hardware or robotics), who can help me to improve my own understanding and knowledge.
And if you can suggest videos to include, e-mail me at firstname.lastname@example.org, or tweet me at @ReuvenMLerner or @DailyTechVideo. I already have another 4-5 weeks of videos queued up, but I’m always on the lookout for new and interesting ones.
My first ebook, “Practice Makes Python” — containing 50 exercises that will help to sharpen your Python skills — is now available for early-bird purchase!
The book is already about 130 pages (and 26,000 words) long, containing about 40 exercises on such subjects as basic data structures, working with files, functional programming, and object-oriented development. But it’s not quite done, and thus I’m calling this an “early-bird” purchase of the book: Not all of the exercises are ready, the formatting isn’t quite there yet, and PDF is the only format available for now. That said, even in this draft version, there is more than enough here to help many Python developers to gain fluency and improve their skills with the language.
Anyone who purchases the book now can use the coupon code EARLY to get a 10% discount. Perhaps it goes without saying, but anyone buying the book now will also get all updates and improvements, free of charge, as they occur over the coming weeks. And anyone who finds that they didn’t get value from the book is welcome to e-mail me and say so — and I’ll refund 100 percent of your purchase price.
The basic idea behind “Practice Makes Python” is that learning Python — or any language — is a long, slow process. Even the best courses cannot possibly give you enough practice with the language for it to feel natural. That only comes with practice. Most people end up practicing, as it were, on projects at work. My goal with this book is to give people who have taken Python courses a chance to become more familiar with the language.
My PhD studies in Learning Sciences taught me a great deal about how people learn, and one of the most important lessons was that of “constructionism” — that one of the best ways to learn is through the creation of things that are important to the individual. I have tried to make the exercises in “Practice Makes Python” interesting and fun, as well as relevant to what people do with Python on a day-to-day basis. Perhaps you won’t be creating Pig Latin translation programs in your day job, but the techniques that you learn from writing such programs in the book will undoubtedly help you out. Certainly, by working through the exercises — not by reading the answers and discussions! — you will learn a great deal about Python programming.
If you recently took a course in Python, or even if you have been working with it for up to a year, I believe that “Practice Makes Python” will give you the knowledge and confidence you need to master this fun and interesting language. These exercises are based on the many Python courses I have taught in the United States, Europe, Israel, and China over the years, and have proven themselves to help programmers start to really “get” Python.
I’d be delighted to hear what you think about “Practice Makes Python,” and how it can help to improve people’s Python programming skills even more. Contact me at email@example.com if you have thoughts or ideas.
I love developing software. I also love helping people to learn how to develop better. That’s why I have been teaching programming classes for more than a decade, and why I write about programming. There is so much to learn; it’s a rare day on which I don’t learn something new, and it’s a rare week in which I don’t apply some new understanding to a problem that I’m solving for a client.
Now that I have finished my PhD, I have some more time to focus on creating products that I believe will help people to program better. I’m pleased to announce three initial such products, all aimed at Python developers who want to improve their skills:
These products (well, the paid ones, anyway) come with a full, 100% money-back guarantee. And of course, if you have questions, you can always contact me via e-mail.
In the wake of my last blog post, I’ve been thinking a great deal about the practice of teaching, and specifically the practice of teaching programming. I’ve realized that while instruction in programming is increasingly popular and important, the people engaged in such instruction aren’t comparing notes, learning from one another, or generally working to improve the trade.
I’ve decided to try to change that. I’ve created a new site, Teaching to Code, a discussion forum aimed at anyone who teaches programming to others. Whether you teach in person, produce screencasts, or lecture at the university level, I’m sure that there are techniques, ideas, and suggestions that you can share with other people, and which can help to improve the craft of teaching programming.
It’s true that many of us in this community are commercial instructors. As a result, there will undoubtedly be some overlap and competition among the people who participate. I’m optimistic that we can balance these competitive instincts and realities with the goal that we all (presumably) have, namely to improve our students’ knowledge and understanding of programming in general, and of the technologies we teach in particular.
In addition to general discussion on a variety of topics, I’m also aiming to have a monthly book/journal club. Each month, we’ll discuss a book, journal article, or blog post (or even a video, I guess) that can inform and improve our teaching. Some of the initial suggestions will come from readings I’ve had in graduate school; there were a number of papers that have really influenced my thinking, and that I believe will be interesting and useful for others, too. But I know that I’ve only read a minority of things written on this subject, and would be delighted to read and then discuss these items, as well.
If you’re a programming instructor of any sort, please join us! Contribute to the fledgling discussion, and suggest how we can make it better. If there is something that you feel could help you, or improve your teaching, then you can either ask on the forum or e-mail me at firstname.lastname@example.org. Either way, I hope that Teaching to Code will become a community of practice for programming instructors worldwide, helping teachers and students alike.
Several weeks ago, my wife and I saw a wonderful play at our local theater in Modi’in (“Mother Courage and Her Children“). At the end, the actors came out to receive their richly deserved applause. Three times, the actors came out, took their bows, and were warmly applauded by the audience. We loved their performance — but just as importantly, they loved performing, and they loved to see and hear the reactions from the audience, both during and after the play.
I’m sure that some or all of these actors have worked in television and the movies; Israel is a small country, and it’s hard for me to believe that actors can decide only to work in a single medium. But I’ve often heard that actors prefer to work on stage, because they can have a connection with the audience. When they say something funny, sad, or upsetting, they can feel (and even hear) the audience’s reaction.
But while we often hear about TV and movie stars making many millions of dollars off of their work, it’s less common for stage actors to make that kind of money. That’s because when you act on stage, you’re by definition limiting your audience to the number of people who can fit in a theater. Even the largest theaters aren’t going to hold more than a few hundred seats; by contrast, even a semi-successful TV show or movie will get tens or hundreds of thousands of viewers on a given night. (And yes, TV and film have many more expenses than plays do — but the fact remains that you can scale up the number of TV and film viewers much more easily than you can a play. Plus, movies and TV can both be shown in reruns.)
Another difference is the effort that you need to put into a stage production, as opposed to a TV program or a movie: In the former case, you need to perform each and every night. In the latter, you record your performance once — and yes, it’ll probably require multiple takes — and then it can be shown any number of times in the future. You can even be acting on stage while your TV show is broadcast. Or more than one of your movies can be shown simultaneously, in thousands of cities around the world.
What does this have to do with me? And why have I been thinking about this so much over the last few weeks, since seeing that play?
While I’m a software developer and consultant, I also spend a not-insignificant time teaching people: In any given week, I will give 2-4 full days of classes in Python, Ruby, Ruby on Rails, PostgreSQL, and Git, with other classes likely to come in the next few months.
I’m starting to dip my toes into the waters of teaching online, and hope to do it increasingly frequently over the coming months and years. But unlike most online programming courses currently being offered, I intend to make most or all of my courses real-time, live, and in person.
This has some obvious disadvantages: It means that people will need to be available during the precise hours that I’m teaching. It means that the course will have to be higher in price than a pre-recorded video course, because I cannot amortize my time investment over many different purchases and viewings. And it means that the course is limited in size; I cannot imagine teaching more than 10 people online, just as I won’t teach an in-person class with more than 20 people.
Given all of these disadvantages, why would I prefer to do things this way, live and in person?
The answer, in a word, is: Interactions.
I’m finishing my PhD in Learning Sciences, and if there’s anything that I have gained from my studies and research, it’s that personal interactions are the key to deep learning. That’s why my research is all about online collaboration; I deeply believe that it’s easiest and best to learn when you speak with, ask questions of, challenge, and collaborate with others, ideally when you’re trying to solve a problem.
I’m not saying that it’s impossible to learn on your own; I certainly spend enough hours each week watching screencasts and lectures, and reading blog posts, to demonstrate that it’s possible, pleasurable, and beneficial to learn in these ways. But if you want to understand a subject deeply, then you should communicate somehow with other people.
That’s one of the reasons why pair programming is so helpful, improving both the resulting software and the programmers who engage in the pairing. That’s why open source is so successful — because in a high-quality open-source project, you’ll have people constantly interacting, discussing, arguing, and finally agreeing on the best way to do things. And that’s why I constantly encourage participants in my classes to work together when they’re working on the exercises that I ask them to solve: Talking to someone else will help you to learn better, more quickly, and more deeply.
I thus believe that attending an in-person class offers many advantages over seeing a recorded screencast or lecture, not because the content is necessarily better, but because you have the opportunity to ask questions, to interact with the teacher, to clarify points that weren’t obvious the first time around, and to ask how you might be able to integrate the lectures into your existing work environment.
So for the students, an in-person class is a huge win. What do I get out of it? Why do I prefer to teach in person?
To answer that, I return to the topic with which I started this post, namely actors who prefer to work on stage, rather than on TV and in movies. When I give a course, it’s almost like I’m putting on a one-man show. Just as actors can give the same performance night after night without getting bored, I can give the same “introduction to Python” course dozens of times a year without tiring of it. (And yes, I do constantly update my course materials — but even so, the class has stayed largely the same for some time.) I’m putting on a show, albeit an interactive and educational one, and while I put on the same show time after time, I don’t get tired of it.
And the reason that I don’t get tired of it? Those same interactions, which are so beneficial to the students’ learning and progress, are good for me, as the instructor. They keep me on my toes, allow me to know what is working (and what isn’t), provide me with an opportunity to dive more deeply into a subject that is of particular interest to the participants, and assure me that the topics I’m covering are useful and important for the people taking my class.
I live and work in Israel, and one of the things that I love about teaching Israelis is that I’m almost guaranteed to be challenged and questioned at nearly ever turn. Israelis are, by nature, antagonistic toward authority. As a result, my lectures are constantly interrupted by questions, challenges, and requests for proof.
I have grown so accustomed to this way of things, that it once backfired on me: Years ago, I gave a one-day course in the US that ended at lunchtime — it turns out that the Americans were very polite and quiet, and didn’t ask any questions, allowing me to get through an entire day’s worth of material in just half of the time. I have since learned to make cultural adjustments to the number of slides I prepare for a given day, depending on where I will be teaching!
When I look at stage actors, and see them giving the same performance that they have given an untold number of times in the past, I now understand where they’re coming from. For them, each night gives them a chance to expose a new audience to the ideas that they’re trying to get across through their characters and dialogue. And yes, they could do that in a movie — but then they would be missing the interactions that they have with the audience, which provide a sense of excitement that’s hard to match.
Does this mean that I won’t ever record screencasts or lectures? No, I’m sure that I will do that at some point, and I already have some ideas for doing so. But they’ll be fundamentally different from the courses that I teach, complementing the full-length courses, rather than replacing them. At the end of the day, I get a great deal of satisfaction from lecturing and teaching, both because I see that people are learning (and thus gaining a useful skill), and because my interactions with them are so precious to me, as an instructor.