The Framework Coder on the Tractor

My previous post “The Degradation of Java Developers” sparked several interesting discussions. One of the major topics was if today’s developer has to know what’s going on under the hood of a particular framework. To be more specific, if Hibernate, a popular object-relational framework, can hide from your how the database objects are being created or manipulated, why learn SQL? One reader stated, “First of all, Hibernate (JPA, actually) is a step forward since it reduces most of the boilerplate SQL of the obvious kind. In applications with around 100 tables in the SQL database it is not challenging to explicitly write data access objects by hand.”

I can agree with this to some extent, especially when we talk about such mature and stable framework as Hibernate. But this framework was created to spare the programmer from writing tons of mandane SQL and JDBC code. Hibernate might help you here, but it’s hard to imagine that if the storage consists of 100 database tables no queries created by Hibernate have to be fine-tuned and optimized. In such cases if a person who uses Hibernate doesn’t know SQL – it turns him into a useless team member.

About two months ago I was making my usual morning promenade along the beach. Every morning a couple of tractors are moving back and force leveling the beach surface destroying the sand castles and burying butts and seaweed. All of a sudden, one of the tractor’s wheels got stuck in the sand.

The driver started angrily pushing the pedal or whatever else there is to push, making the tractor move back and forth slowly but surely getting deeper and deeper into the sand. When the tractor’s belly was literally laying on the sand, the driver realized that he won’t be able to get the vehicle out of the sand himself.

I was observing the entire show from the beginning of submerging till the moment he started to call for help using his cell phone. This is when I took the picture. What struck me the most was that during all this time the driver didn’t even bother to step down from the tractor to do anything manually to prevent the submerging. He didn’t bother and he was not trained for these kinds of situations. I assume he was told to call the office in case of any extraordinary situations. Houston, we got a problem!

Do you see the analogy with a framework coder who doesn’t know how things work under the hood? I clearly do. I also know that among the tractor drivers that are working on that beach there are people who know how to fix these situations without calling for a tow truck.

On the same note, each team of programmers includes a person who knows how to fix everything starting from fine tuning SQL all the way to fixing broken builds or writing manual piece of code that performs better than a framework.

Some developers who use open source frameworks know that if there is a bug in the framework or some feature doesn’t exist they file the bug or request for improvement with the vendor and then happily report to their managers that we have to wait till the vendor will fix it. But there are people who understand the words “open source” literally. Yep, they open the sources, read the code, subclass the problematic classes and make the fixes on their own.

The question is if IT managers understand and promote those people who are not afraid to roll out the sleeves. It helps if the software developers know how to manage the manager. But this is a topic for another blog.

P.S. Replacing SQL with a 500-page long JPA spec “to make my life easier” is not a good idea unless you really need various types of data storage. In 99% of the today’s enterprise applications it’s not needed. But my kudos to the Sun/Oracle tandem for brainwashing millions of Java developers into believing that learning JPA is better than learning SQL.

The Degradation of Java Developers

On multiple occasions I was blogging about these legions of enterprise Java developers trained to use certain frameworks without understanding how things work under the hood. This morning I had chance to see it one more time after interviewing three job applicants in a row.

Our consulting company got a request for a well rounded Java developer with the knowledge of SQL. We have good reputation with this client, so I started screening the candidates, which I got from a recruiting agency.

First, about the resumes – each has several pages with detailed description of their work for various employers. Each resume had a list of technologies that the candidate supposedly know. Here’s the list of technical skills from a real resume:

Core Java, J2EE, JSP, JDBC, Servlets, AJAX, XML, HTML, XSLT, Web Services, CSS, JavaScript, SQL, Oracle 10g, MySQL 5.0., JMS,Eclipse, Adobe Flex Builder 3.x,UML, JDBC, SVN, JUnit, VSS, Jira, HTML, DHTML, CSS, AJAX, JavaScript, XML, MXML, Action Script, Servlet, JSP, JSTL, Hibernate 3.x, Spring 2.x, IBatis, SOAP, UDDI, WSDL, Apache Axis, Web logic Server 8.x, Apache Tomcat 5.0, Struts Framework, MVC, ANT, Maven.

Looks impressive… for those who haven’t been interviewing Java developers. I don’t want to say that this candidate is lying, but he wasn’t able to maintain a conversation about 80% of these technologies for more than 3 minutes. They’ve heard or even tried working with these technologies or tools, which is all that’s needed for adding them to the resume. What are the remaining 20% they can talk about? The frameworks. Most likely they will explain how to configure Struts or Spring, and even how to make Spring talk to Hibernate. BTW, they all love Hibernate cause it spares them from writing SQL, speaking of which, they know very little about this query language.

When I see all these Struts, Springs, and Hibernates on the resume I start with this, “Imagine, that you’re not allowed to use any frameworks. Explain in details the entire process of bringing the data from DB tables Customers and Orders to the Web page”. For most people it’s a killer proposition let alone writing some SQL queries…

One person had JQuery on the resume. I asked her, “Why did you use jQuery”…20 sec pause…”I like it, it’s nice!” That all I could pull out from her on the subject.

Two weeks ago I’ve attended a technical keynote at JavaOne in San Francisco. Brian Goetz was showing code samples of Lambda Expressions (a.k.a. closures) that will be introduced to Java 8 next year. This is a pretty advanced feature and proposed Java syntax is not for the faint of heart. I was thinking to myself, “Who’s going to use these closures in the enterprise Java world? 10% of the developers? 5%?”. Are these expressions being introduced just for fun cause it’s cool and other functional languages have them?

Software development industry is changing. It doesn’t need hackers anymore. It needs craftsmen who can configure and replace blocks of code when something stops working. Ideally, you should have in your team one Java expert who can actually understand the code of your application and can fix it not on the block level, but can drill down to a single line of the Java code. Somehow such people also know how to write a SQL outer joins, how to fix the broken build, and whatever else may come up.

A typical enterprise manager wants to increase the population of his software developers. Managing more people is the shortest way for moving up the career ladder. It is what it is. But if you are smart enterprise manager, make sure that for each dozen of framework programmers you have at least one real.

I already received a new resume for tomorrow’s 10AM interview. The resume looks the same. The only lines I read are the names of the former employers and projects. Any other written information is useless – the real picture will start developing tomorrow at 10AM.

Tomorrow’s Update. It’s 10:15AM. Yet another interview is over. The fourth wrong answer was that to send the data to the browser a servlet has to add it as an attribute to the HTTPSession object. Do you think it would be rude to stop the interview after listening to such answers for 10 minutes?

The Day After Tomorrow’s Update.I’ve added $5 to the hourly rate offered for this position. The very first candidate passed my interview with flying colors. Never thought that a lousy five bucks can open the door to the wonderful world inhabited with intelligent Java developers!

A Thousand Presentations Later

Many years ago I prepared my first PowerPoint slide deck and used it as visuals in front of a small audience. Over the last twenty years I made tons of presentations on IT related subjects. In this blog I’d like to share with you a dozen rules I use while preparing my slide decks or speak. Please add your comments with more tips to rookie presenters.

1. The font has to be as large as possible – not less than 18pt for the text and 12 points for code listing. If you can’t fit the entire code fragment on one slide, split it in two or create two code panels on the same slide.

2. Do not abuse effects and transitions like spinning, rolling, fading slides or texts. Using them once in while is fine, but keep the attention of your audience by the quality content and not by showing them how your slides dance on the screen.

3. Don’t use multi-color master slide themes. Here’s an example of the master slide I received from one conference organizers (they were really nice people). Add some content to it and the audience will get headache after spending an hour trying to weed our the content from the unneeded background.

4. Do not create presentations with 16×9 ratio unless you’re always using your own projector. Be prepared to present on the outdated projector provided by your host. Your presentation should look good on a 1024×768 projector with a 4×3 ratio.

5. If possible, keep the bottom 10% of the slide blank. People on the back may not see that portion if a basketball player is sitting on the first row, and the screen is hanging low.

6. Do not use constant screen zoom in/zoom out using these gestures on the trackpads – it makes people dizzy. Better increase the font size of whatever text you want to present.

7. The amount of text you put on each slide has to be minimal. Not as minimalistic as in Steve Jobs’ presentations, but having 3-4 short sentences on the slide is more than enough. Don’t just read the text from your slides – comment the slide content.

8. If you are planning to share your slides with the audience, upload the slide deck in a PDF form to your server or slideshare.net and include the URL on your first slide. 50% of the conference organizers’ promises to publish the slides never materialize.

9. How many slides you need, say for a 50-minute presentation? I need 25 – my empirical formula is 2 minutes per slide. This doesn’t include time spent on software demonstration, visiting external Web sites (Internet won’t work), or going through the program code.

10. Assume that the Internet won’t work at the venue . Pre-record video fragments of whatever you wanted to present live and use it as a Plan B (or is it Plan A?)

11. What if the projector doesn’t work? Five years ago I had this experience in a pretty large conference in New York City. I’ve been presenting for 40 minutes without any visuals other than my body language.

12. Can you still deliver the presentation if your slides got corrupted or your laptop got stolen? Sure you can if before starting your trip to the venue you’ve saved your powerpoint as a PDF file and uploaded it to a publicly available server. This way you can use any computer that has Acrobat Reader installed. Some people believe that it’s cool to make a no-slide presentation to a room full of software developers. They program live on stage. The audience seems to be happy too. How cool is that! Then the show is over. The magician is gone. What are all these people left with? Sweet memories.

Memory
All alone in the moonlight
I can smile at the old days I was beautiful then
I remember the time I knew what happiness was
Let the memory live again

Of course, experience matters. But the most impressive Powerpoint presentation I’ve seen till now was the one made by my younger son when he was a 9 year old kid. One night he just invited my wife and myself to his room, turned on the projector and started showing simple slides of him doing a good job in school and a picture of himself being bored at home spending evenings alone in his room. The final slide of this short preso was showing a newly released Game Boy console with a large font text “Please purchase it for mе. Don’t I deserve it?”

This was а perfectly made and delivered presentation that was concise, up to the point, and most importantly, it achieved the goal of the presenter.

Why Grade Students of Vocational Schools?

Yesterday, I started teaching my regular online training to people who want to learn Java programming. This class is not a part of any University program neither it’s paid for by the Unemployment Administration. It’s an open enrollment class – people from various countries either decided to improve their marketability or learning Java would help in their current job assignments.

The class runs online twice a week, and yesterday, I announced that after each lesson they’d be given a homework that should be submitted by our next session. One of the students asked if submitting a homework is mandatory. I said, “No”, and this is what I’d like to discuss in this post.

Students’ motivation (or lack of thereof) is THE most important factor of the success of any training. But what about the instructor’s motivation? Since this training is a private enterprise, I don’t need to report to any organization if my students succeeded in studying Java. I don’t need to prepare reports showing straight A’s and B’s.

Do I really care if my students will succeed in learning Java? Yes I do, because I enjoy teaching software. Yes I do, because I care about my reputation. The Internet made our planet Earth really small. Several bad reviews of my training classes may seriously hurt my reputation and the future business. I don’t want this to happen. In today’s world the users’ reviews and ratings drive business.

Each of my students paid for this training about $700, which for many of them is a vary large chunk of change. Yet the fear of wasting this amount by not studying hard doesn’t seem to be strong enough if people ask if submitting homeworks is mandatory.

They know from the feedbacks of my previous students that the quality of my trainings is high, so they enrolled. Now some of them are making themselves comfortable in front of their monitors located thousand miles away from me getting ready to see how I’m going to turn the water into wine. In every group I teach there are people who enrolled to see a miracle rather than working hard. Do I have to humiliate these people by forcing them to submit homeworks and giving them poor grades? I don’t think so.

As long as I honestly and professionally do my job, I sleep well. And I will deliver a miracle. I will heal all crippled men who really want to be healed, and they will join the huge community of Java professionals. Hopefully those who won’t be healed will be honest enough to post the online reviews witnessing the miracle.

How to Become a Professional Software Developer

I’ve recorded this video about IT career based on my last week’s talk at the Java developers conference in Kiev, Ukraine. This is not a technical presentation, so anybody can listen to it.  You may not agree with what I say, but hey, it’s my today’s opinion formed during my rather long career in IT.

In this presentation I touch upon the following subjects:

  • The process of looking for a job (sending the resume, passing the interview, considering a offer, discussing the salary)..
  • What’s the difference in interviewing Ukrainian and American programmers.
  • Comparing employees and contractors.
  • Are you really a senior developer?
  • Keeping your skills up to date.

You can watch the video here.  If you prefer, just download the mp3 and listen to it on the go. Back in 2008, I self-published a free e-Book titled “Enterprise Development Without the BS“, which is also covering  IT career subjects. Give it a read.

Back From The Java Conference in Kiev, Ukraine

Last week I spent three days in Kiev, Ukraine participating in a new but rapidly growing Java conference titled JEEConf.  The city of Kiev is more than 1500 years old, and will host the European Football Championship in two three weeks.  During the first two days I was running two hands-on classes: one on JavaScript and another – “Intro to Java EE 6”. The one-day class “JavaScript for Java Developers” was an intensive way to learn this interesting language that requires Java developers to re-think their way of programming. The Intro to Java EE is a quick way for people who know Core Java to get familiar with the server-side technologies. In the last moment, I threw in there some materials explaining what Ajax and JSON are. They’re not the part of Java EE just yet, but play an important part in the architecture of many of the real-world Web applications.

I’ve spent the third day at this 650-attendees-4-track conference. The organization of the event was excellent (thanks to the folks from XP Injection – a training center from Kiev). That day I was delivering a non-technical preso on “How to become a professional Java developer”. It was about how to prepare a resume, minimize failures during the technical interviews, what not to do while resigning… Long story short – it was about actively building your career.

This presentation was taken really well by the 400+ people in the attendance. After presenting for one hour I had to spend another 40 minutes in the corridor answering lots of questions. Even though the vast majority of the audience were appreciative my the honest coverage of how I see the complex game called “Looking for Job”, I need to say that there were a couple of people who didn’t get it. I’ve seen a comment stating that I was teaching people how to lie at the technical interview. It’s like accusing a football coach of teaching the team players how to make tricks with the ball.I guess, from their point of view, a player should hit the ball straight ensuring that the other team always know where the ball goes next.

I didn’t have problems explaining the audience how to negotiate their salary regardless of the fact that I’m recruiting people from Ukraine and these newly acquired skills can cost me. I call this a fair game. In about a month, the video of this presentation will be published at the conference’s Web site, and if you understand Russian, you can form your opinion of what it was about. The English-speaking audience can go through the Powerpoint slides. BTW, I delivered a similar presentation in Bangalore, India at the First Great Developer’s Conference three years ago.

I enjoyed being in Kiev, the city I’m originally from. I enjoyed talking to young Ukrainian developers. I enjoyed seeing how the audience participated in discussions in English with the world-class speakers well known in the Java community (Arun Gupta, Sander Mak, Dejan Bosanac). I enjoyed being at this young, but very promising Java event. You can find photos and more of the feedbacks about JEEConf over here.

Thanks again to the conference organizers.   IMHO, it would be nice if next year you’d create and maintain a full English version of JEEConf’s Web site. Keep growing guys!

What not to Bring to an IT Conference

In May, I’m flying to Kiev, Ukraine to participate in a Java conference there and this won’t be the only conference I’ll be going to this year.  For software developers the ability to attend a major professional conference is a valuable perk given by their employers. OK, all expenses are approved and your air flight and hotel in Kiev, Paris, San Francisco, or New York City are booked.  It’s time to ask yourself, “Why you wanted to go to this conference to begin with?”

Changing daily routines can be a good reason in an of itself. But the main purpose is to sharpen your skills and meet new people, right? So what you shouldn’t bring with you to the conference?

1.    Leave your laptop computer in the hotel room. Don’t bring it to the conference venue unless you’re giving a presentation on this day. Computer is a major distraction in any conference. You’ll be spending a large portion of the day finding a wi-fi hot spot that will give you at least 56Kbps connection.  Internet connections are notoriously bad on any conferences, and this will make you irritated and upset.

Look at all these people sitting on the floor by the electric outlets. Their computers need juice. For what? For checking Facebook, tweeting, and browsing your work emails? Do this experiment for me. When you see such a floor person in a classroom, sit down next to him and ask in a low voice, “Excuse me, do you know what is this presentation about?” In the best case scenario, it’ll take him some time to remember what he’s “learning” in this session.

You may argue, “I’m using my computer to take notes.” Really? What’s wrong with a simple yellow paper notepad? It’s light to carry and doesn’t need power.  Do you really take such detailed notes that the power of word processors is required? I saw a person once who even used some mind mapping software for taking notes. Looks impressive, but I’m not sure if I wanted to check in the code to the same repository with such an over-organized person.

Better bring  a small camera with you and take a quick shot of the presentation slides you like. And no, it doesn’t have to be Nikon D90 – point and shoot will do.

2.    Leave your smartphone (a.k.a. sacred cow) in the hotel room too. “But what if someone will need to call me?”  Cut them lose. You’re not available. You are attending a conference, don’t they know? The world won’t stop without you. “But I could use my smartphone for taking pictures instead of bringing the camera, right?” No, No, and No. While carrying a camera will force you to pay more attention to what’s going on around you, the smartphone will do the opposite.

3.     Don’t let your spouse fly with you to SF, NYC, or wherever the conference takes place. “Honey, if I’ll go with you, we can save on the hotel and your airfare is paid by the employer too!”  And I say “No, no, no!”  You got to be partying with other geeks like you. Having your spouse nearby is a major destruction for networking with your peers. Having a spouse at a conference is even worse than carrying a smartphone on you. Don’t try to kill two birds with one stone. Take her to a romantic vacation after the conference. Let her arrive to this city on the day after the conference is over.

4.    Don’t bring your tux. In IT conferences, to be considered a geek, you have to dress as casual as possible (the clothes must be clean though).  Exposing your body covered with tattoos and piercing is the easiest way to be perceived as a guru especially, if this conference includes the creative people like Flash gamers and Web designers.

5.    And most importantly, don’t bring your ego with you. Who cares if you’ve published a book for dummies, three articles, and the plate on your office reads “Senior VP”?  Here you are just one of many people who devoted their lives to IT – enjoy the moment!

Identifying Design Patterns in Resumes

Just got an email from a person who calls himself a Senior Java Developer. Two out of five pages were devoted to  describing his skills. Below is an extract from the Skills section:

Java 2 (J2EE, J2SE) rich operational experience
JDBC 2.0. rich operational experience
EJB considerable operational experience
SQL rich operational experience
JSP rich operational experience
JSTL rich operational experience
Servlets rich operational experience
Struts rich operational experience 
GWT considerable operational experience
Spring framework rich operational experience

The list would go on and on. I didn’t even need to interview this candidate – it’s clear that he can’t be senior.  He already violated the Don’t Repeat Yourself (DRY) design pattern.  I can imagine what his code will look like…

Java, Soviet Union, and Job Interviews

Back in the seventies, I was taking entry exams to the Kiev Politechnic Institute (KPI). I lived in Ukraine, which was a part of the Soviet Union. At that time people of the Jewish descent had really hard time in getting into most of the colleges and universities. Typically, there were four entry exams for the engineering majors: the verbal math, the written math, the verbal physics, and essay. There were no such things as multiple choice tests ndash; we had to solve problems.

Being a Jewish boy myself, I was raised knowing that getting into college will be extremely difficult for me, and I had to be much better prepared than regular Ukrainian and Russian kids. I was strong in math (can’t say this about the Physics though).

Anyway, during the first written test at KPI, there was a problem with the purposely wrong description. Each of the four hundred people that were taking this test had to solve it. I caught the trick in that problem, and my written math grade was 4 out of 5. Two hundred and twenty people got 2 out of 5, which meant that they wouldn’t even accepted to the second exam.

At the verbal math exam, each applicant had to randomly pick a sheet (a.k.a. ticket) with different written problems. Everybody was sitting in a large auditorium preparing their answers followed by the face-to-face conversation with a professor. He or she was reviewing your solutions and could ask additional questions.

I glanced at my sheet – all problems were easy for me. I quickly wrote the answers, then helped to a girl sitting next to me (this was her 5th attempt to get admitted) and wrote all the answers to the guy in the military costume – guys who server in the army had a preferential treatment (you may be surprised, but helping other people during the tests was considered a noble thing to do in the USSR). Each of them had a face-to-face before me and each of them got a quick 4 without any additional questions. I said to myself, that if they got 4, I could expect getting 6 out of 5.

Then was my turn. All answers for the ticket problems were correct, and then the professor started to ask me additional questions. After answering 11 (!) questions correctly, he asked me the next one from trigonometry, “What’s the difference between the graphs of functions arcsine and arccosine”. Piece of cake. I started answering “The function arcsine looks the same as arccosine,  …” He didn’t let me finish or draw the graphs. “Stop. So you think that arsine and arccosine look the same? Your grade is 2 (failed). ” This meant the end of my exams. No i understand, that I should have selected each word more carefully, but getting 2 after seeing how people who know nothing are fetting 4?

I was speechless for a moment… He didn’t let me finish the sentence! I started mumbling that I was awarded a second place in the math Olympiad of the central borough of Kiev. Then I pooled out the award certificate… He just said, “Apparently your math was better back then, but now you have a serious gap in trigonometry ”

Two months later I went to Novocherkassk, Russia, which was a town 600 miles away from home, got two easy fives on both math tests, 4 on essay and 3 on physics, and got admitted to the Applied Math major.

Several years ago, I was browsing books on Amazon and found a pretty interesting one – “You Failed Your Math Test, Comrade Einstein “. The authors compiled many tough math problems that were prepared specifically for the Jewish students applying to the Soviet “ivy league ” universities. I bought this book to show my respect to the authors for their work. People who live in Ukraine now, tell me that this practice is gone, and everyone has equal opportunities on entrance exams…I wish all the best to the people of Ukraine.

So what does all this have with Java and job interviews here in the USA? These days I often interview people who apply for jobs. A face to face interview is similar to that entrance verbal exam. The only difference is that in the USA people are graded based on their skills rather than ethnicity.

But let’s imagine for a moment that you are conducting a technical interview on Java programming and need to have a special question to ensure that the person you don’t like won’t pass. I ‘m going to arm you with one.

After years of interviewing enterprise Java developers of different levels, I can attest that 90% of them don’t bother learning new features of the language and just get by using whatever they learned some time in their past. For example, nine out of ten people still believe that there are only two way of creating a Java thread ndash; subclass a Thread or implement Runnable. You also thought so? I know. The “new way rdquo; was introduced to Java only six years ago. You want to learn another way? Get my recent book “Java Programming. 24-hour Trainer. ”

Here’s the killer question that 95% of the Java programmers won’t answer correctly. “Give all examples of usage of the keyword final”.

The candidate sits quietly for 30 seconds just to show that he ‘s thinking about the best way of answering this easy question, then he writes the following on a piece of paper:

– If a method declared final, this method can’t be overridden.

static final double convertToCelsius(double far){

return ((far – 32) * 5 / 9);

}

–  If a class is declared final, you can “t be subclass (extend) it

final class Tax { …};

– The value for the final variable can be assigned only once

static final int BOILING_TEMP = 212; // in Fahrenheit

Say politely, “Great, this is correct. Are these all uses of the keyword final that you can recollect? ” As I said earlier, the chances that the candidate knows the fourth use are about 5%. He goes, “Java has no any other use of the final keyword, I ‘m positive.” At this point you thank him for giving you great answers and say that an HR person will be in touch shortly. This is one of the major differences between the USA and USSR. We don’t say give the final answers while the candidate is still here. The phrase “Your answer is wrong ” or “You have a serious gap in trigonometry” could lead to unpredictable reaction of the candidate. We don’t want any conflicts. Let him leave in peace.

The mission is accomplished – he failed the job interview!

Recently released Java 7 has a new feature called final rethrow. In my opinion, it’s a pretty useless feature you can live without. Besides, it makes the code more difficult to read. Now, it’s legal to write something like this:

private void throwExceptions() throws A, B, C {

try {

throwAccordingToIndex(new Random().nextInt(2));

} catch (final Exception e){

System.out.printf( “Caught %s and rethrowing…%n “, e);

throw e;

}

}

To make things even more confusing, writing the keyword final here is not mandatory. But hey, the candidate didn’t know about this use, which means that his skills on Java are not current. And our team of sharp developers don’t need people with rusty skills. For the next several years this question will help you eliminating the candidates you don’t want to have beer with. No one will use this feature, and Java practitioners won’t have a chance to see it in anyone’s code.

Do you like my strategy? Neither do I. I’ll remember that episode with arcsine till I die, and will never apply such techniques while interviewing candidates. So why did I write this blog? To be honest with you, I don’t know. For some reason, when I learned about this feature, I couldn’t find any other use for it other than a secret weapon for the dirty interviewers.

Update. After re-reading this blog, I realized that it didn’t cover an important use case: what if the job applicant knows about this fourth use of the final? Ask what he thinks about this new feature. If he has any opinion about this feature, hire him. He follows the latest developments in the Java language and cares to form an opinion.

Seven Rules for Presenters and Instructors

During the last 15 years I’ve presented at dozens of conferences and taught hundreds of training classes on various programming subjects. I’ve been attending or watching lots and lots of different technical presentations. In this article I’ll give you my opinion of bad and good practices of speakers and presenters.

1. Show of Hands. This is popular but bad habit. Have you ever been to a presentation that starts with 3,4,5 questions like “Raise your hand if you are using so and so software for less than 1 year “. “Now, between 1 and 3 years?” “Let me see a show of hands: who used this framework in a real project?” And on and on and on. Why wasting time of the audience on this BS? You’ve got only 45 minutes to make your point. Just get straight to the meat of your talk. People in the audience are not idiots. They’ve read the description of your talk in the conference brochure, and decided that your talk has some value. They are sitting here for a reason. What if the show of hands reveals that 70% are mid-level developers and 30% are beginners? Will you ignore the interests of these 30% and cover the subject addressing only more experience crowd? This is dead wrong. This is a conference and not a private tutoring gig, where you can cater to the needs of the single person. Include in the description of your talk the expected skill level of your audience and present.

2. Masturbation. The goal of your presentation is not to enjoy yourself and please your ego. People should get some satisfaction too. They came here to learn from you not because you’re God, but because you had a chance to research this particular subject better. Showing your expertise is fine, but give people something they can use in their daily routines.

3. Timing. People prepare slides without bothering if they’ll have enough time to go through all of them during the available time slot. Recently I asked someone to give a 45-minute talk and send me his slides in advance. When he sent me a 30-slide deck, it was clear that he won’t make it in 45 minutes. I use a simple rule – you need two minutes per slide (I’m not talking about Steve Jobs type of slides contaning just one word iPhone or iPad). Time your preso or you’ll end up with “How are we doing on time? Only 5 minutes left? OK, I’ll wrap up real fast. Anyone can grab me in the corridor.” Yeah, right!

4. Visuals. Some presenters believe it “s cool to bash powerpoints and start their presos with statements like “This is a one slide show. I won’t waste your time flipping slides – we’ll get straight to coding!” The crowd roars in joy – finally, the real geek is on stage. No fluff! The presentation went fine, the star is gone, and what are you left with? Nothing. Yes, he proved that he could do it. Now what? Can you repeat it at home without any visual materials supporting this talk? Most likely not. Prepare your slides and upload them to YOUR server BEFORE your talk regardless if the conference organizers promise to publish them after the event. Include the link to your slide deck on the first or last slide. And please, use the largest font size you can so people on the back can read it.

5. The 2-Minute Rule. This pertains to a classroom situation, when one student can’t complete the exercise because he ignored some required configuration steps. You were trying to help him… 5, 7, 10 minutes passed, but it didn’t work anyway. Other students start browsing Internet or check their emails. Last week I was running a training class where students were supposed bring their laptops with installed Eclipse 3.6 for Java EE developers and Apache Tomcat 7. But some students decided to do better. They “ve upgraded to Eclipse 3.7 that came out one day before the class. One guy had Eclipse for PHP developers. One person had Tomcat 5.5 installed 3 years ago. They started to have all sorts of errors. In cases like this, if I can’t fix the issue within 2 minutes, I ask the students to re-install the software as per instructions. You can’t steal time from other students just because some early adopters ignored your instructions. Even if this issue is not caused by the student’s wrong doings, move on with the class. Make an early break and help this person, but not at the expense of other people.

6. Ignore the Bosses. In the beginning of a hands-on class, I always ask about the students ” expectations. Yes, 9 out of ten are software developers, and here’s their boss. No he’s not coding, but wanted to join the class to get a better understanding of what tool his people are using. Teach your class as if this big shot is not even there. This is a class for programmers, so keep it this way. Offer the boss-student a 30-minute one-on-one session to give a 30000-feet view of the software, but don’t waste developers’ time just to give the boss a chance to catch up with a group.

7. Frequent Feedback. In hands-on trainings, ask the students every 20 minutes, “Anyone needs help?” Some people are afraid to ask and prefer to struggle with issues alone, while you could have resolved them in a second.

I hope this quick writeup will help you preparing your next presentation. My next presentation is scheduled in New Your City at our annual symposium on software development. Come over and see if I follow these rules myself. If not, grab me in the corridor…