Technical evangelists in IT

If you’ll ask me, “What would be a job you always wanted but never got”, I’d answered, “A Technical Evangelist for a large corporation”. I know how to do it, I like travel, I like meeting new people, and I can convince the IT crowd that the software I believe in is good to have. But. I know many great software developers who are working as technical evangelists for various companies, and I don’t like little tiny things they have to do.

Now I’m watching a recorded presentation of a person I know and respect. He presents a software of his company and compares it with another way of doing the same thing. His slide reads “Our product runs fast, but their product runs faster”. And this is why I never became a technical evangelist working for a corporation. I still can afford to say what I really want to say: “The product A is slow, and the product B is fast”.

This is not to blame technical evangelists that are always on the road working hard to feed their families. I will continue attending their presentations. But I really like the fact that I can afford to say what I really want to say.

Advertisements

Will speak at the Java Conference in Ukraine

Will make two presentations at two-day conference JEEConf in my home town Kiev, Ukraine at the end of May. It’s going to be the largest event for Java developers (about 1000 attendees). I’ve participated in this conference last year, and will go there again with pleasure. Below are the descriptions of my two talks.

1. Surviving as a professional software developer

Last year I made a presentation on how to become a professional software developer (it’s in Russian). This presentation is a sequel. Yakov will present his no-BS point of view on how enterprise IT shops live and operate. He’ll talk about communication skills, bad attitude, the team work, those stupid and useless IT managers, and how the life is unfair if young prodigies have to debug old and poorly-written code. This is not a technical presentation.

2. Speed up your Web applications with HTML5 WebSockets

HTML5 specification includes the communication protocol WebSockets, which is getting more and more popular in the Wall Street real-time Web applications. WebSockets API is include in the upcoming Java EE 7 specification. WebSocket offers solution to the problems of latency, scalability and performance associated with HTTP based solutions like polling, long-polling and HTTP-streaming. Online auctions, financial trading applications, and multi-player games can benefit from implementing WebSockets. This session starts with a brief overview of traditional HTTP protocols followed by covering of how WebSockets works. You’ll see how using WebSockets removes the overhead of heavy HTTP request and response headers. Finally, we’ll review the code of the Web application, where WebSockets is used for the data exchange between HTML-based front end and the latest build of the Java server GlassFish 4.

Fired 15% and Don’t Feel Bad

Back in 2006 I was resigning from a large IT consulting firm to become a partner in a newly created company Farata Systems. During my resignation meeting with a top manager of that firm I asked if he could give me any advice with the new company. He said, “I’ve been managing hundreds of IT people and learned an important lesson – don’t try to hire only the best and the brightest. There are lots of people of various level of expertise in our industry, and they can do the job”.

Since then, I’ve been doing a lot of interviewing and hiring. Our software engineers successfully work on various IT consulting projects as well as on our own software product development. The vast majority of our people work for us for years, which is very impressive given the fact that many of them work remotely from Eastern Europe, where software developers are in high demand. But last year we’ve fired about the half of newly hired contractors. We’ve fired about 15% of people working for our company.

All of them were good software developers. But they were not good enough. When a new hire joins the team working on a project he needs some time to learn the codebase and the tooling. But we expect a person to become productive within 3-4 weeks. If this doesn’t happen, this person becomes a burden for the team. Not only he doesn’t deliver, he requires other team members’ time. We simply can’t afford this. Firing costs us dearly, but we prefer giving such people two-week notices and start hiring again. We want the best and the brightest.

You may say, “You don’t know how to interview people to weed out those that are not a good fit.” It’s not that easy. We are not Google – a dream company to work for. We don’t have candidates camping out by our doors with job applications. We pay better than others, but this is not good enough in the offshoring countries, where many developers would rather work for half pay as employees of the large body shops than as remote contractors. I don’t blame them, but this is a reality we have to deal with.

Unfortunately, the fact that the candidate did well during a couple of phone interviews doesn’t mean that he is a good fit. During the interviews we don’t ask questions like “How many piano tuners live in San Francisco.” We don’t ask to demonstrate hands-on knowledge of algorithms from the book by Donald Knuth. We just need people who care about their profession and know a specific set of software tools.

You’ll be surprised, but even if a person demonstrates good understanding of a certain technology this doesn’t mean that he will be able to apply this knowledge in a real project. If a technical job interview doesn’t work, what does? We started using a new hiring technique: try and buy. This is not about hiring people as contractors and then offering full time employment to those who quality. We offer remote software developers who successfully passed phone interviews to start working on our projects part time without leaving their current employer.

If a person wants to work for us, he can find 40-60 hours to commit for working on our project just for one month. After that, we’ll either make an offer or say, “Sorry”. We pay for this time even if the person didn’t prove to be a good fit for us. It’s less expensive for our company and less stressful for the developers.

We are a software boutique and can afford to hire the best. This worked for us in the past and it will work in the future.

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.