Always buy the latest editions of the programming books

After reading this blog, some of you may say that I was trying to shamelessly promote the book I’m working on, but this was not the goal of this write-up.

Over the years, I’ve authored and co-authored a number of books on programming. In two cases, the publishers asked me to write a second edition. In 2015, the second edition of my Java book was released by Wrox, and this year a second edition of the Angular book is about to be released by Manning.

IMO, the publisher asks the author to write a second edition of a programming book if the following statements are true:

1. The first edition was selling well, and the publisher sees an opportunity for additional revenues
2. A new version of the software has been released, and the first edition became outdated

When I was working on the second edition of my Java book, it became obvious to me that the quality of the materials in the second edition was much better than the first one. Why?

First, while writing a book you spend lots of time researching the subject. The second edition requires more research hence you understand the subject better.

Second, the errors do creep in no matter how many times you and technical editors go through the code samples; there is always something that can be improved or fixed.

Third, the readers of the first edition provide feedback. Some of the feedbacks are just mean (e.g one reader gave me one star on Amazon because the book arrived with scratches), but for the most part, the readers provide constructive criticism, which results in a better quality of the second edition.

Fourth, the more time you try to explain a subject to someone (in the books, blogs, classrooms, or conversations), the better you understand the subject.

Fifth, the readers have different perspectives and the real-world experience. Times and times again, I was saying to myself, “Oh, I didn’t think of it this way!” Re-write!

If you want to understand the subject, write a book about it.

My co-author Anton Moiseev and I are working on the last chapter of the second edition of our Angular book, and both of us are very happy with the results. My hat off to the editors of Manning Publications for nitpicking over tiny details and finding technical errors!

The first edition of this book was recently translated into Polish, Russian, Korean, and Chinese. It’s flattering, but unfortunately, the first edition is already one year old. Too old. Besides, the foreign publisher may hire translators who are not overly familiar with the subject, and the quality of the book suffers. Reading the book in the original language is always better.

If you made it this far, I want to thank you for reading all my ramblings. Check your bookshelf, and place some orders for the latest editions of your favorite software books!


Writing Technical Books 101

So you’re an expert programmer and decided to write a technical book? Think twice. Why do you want to write it? These are possible answers:

1. All these years I’ve been using the IT knowledge so generously shared by other people, and it’s time to give back to the community. Great answer! But does it have to be a book? Have you tried answering other people’s questions on StackOverflow? Have you’ve written a couple of dozen of blogs that people read and like? If the answer is no to any of these questions, start there because writing a book is harder.

2. I want to become a published author. This will give me better recognition in the industry and will look good on my resume. I hear you. This is true unless the book you’ll write will suck. If your book will get mostly negative reviews, you’ll remove it from your resume. But you can’t remove it from the Internet, can you?

3. I want to earn some extra cash in the form of royalties. This is the worst possible reason for writing a technical book, because the money is not there. This is not to say that there are no people making a good living just by writing technical books, but the chances that you’ll become one of them are similar to a fiction book writer becoming the next J.K. Rolling.

I’ll give you some of my numbers. My most financially successful technical book so far is the first edition of Java 24-Hour trainer, which brought me $40K in royalties over four years. Apparently the publisher considered this book a financial success as well, because they offered me to write a second edition of this book. So consider making $10K a year in royalties a good result for your book.

Still want to write your book? Now let me ask you some questions.

1. Do you have a discipline to write every day to meet the schedule? You may be surprised, but the publisher will request your manuscripts to be submitted by the certain dates. The editors will be contacting you asking about the status of your chapters, because they also have their deadlines to meet.

The most common mistake the rookie writers can make is not writing daily. You can’t just live your regular life and write something once in a while. You need to think about your book all the time. Missing a day of writing is a slippery slope, which will require more time and discipline to continue where you left off.

2. Are you ready to listening to valid complaints of your spouse/girlfried/boyfriend that you’re stealing the time from your family, kids, and other fun things you could have done together? And they are right. You are going to be stealing their time.

3. Are you ready to seeing your book illegally distributed for free on all these torrent repos as soon as it hits the book stores? How come? After all this dedication and time spent to make the world a better place they what your content for free? Yes they do. Have you ever downloaded a movie or a song for free without paying for it? You are the same as all these people downloading your book for free. No complains here, but try to turn negative into positive. These free downloads make your name recognizable in the industry, which may be a good thing when negotiating salary or offering training classes.

4. Are you ready to be called an idiot for a typo in the code samples? Actually, I need to give a compliment to my American readers here. They are more polite than the rest of the world , and in most cases will try to give you a constructive criticism.

Still want to write after reading all this? I’m really happy for you! Because I also continue writing despite all these cons. After every completed book project I say to myself, “Never again”, and then start working on a new book.

To summarize, these are some rules I can share with you based on my book writing experience.

1. Never try to make the draft of your chapter perfect before submitting it to the publisher. They’ll modify the text anyway unless you have a college degree in writing, which most software developers don’t. Push the chapter our of the door quickly. Fail fast! Get the feedback as soon as possible to have more time for fixing it.

2. Write every day. Even if it’s just one or two paragraphs. The process has to be continuous. Even the writer-alchoholic Henry Chinaski forced himself to write every day. So booze, gym, or other time-consuming hobbies are not excuses for not writing daily.

3. Don’t write in MS Word or a similar word processor. Use any plain text editor and the Asciidoc markup language with future generation of the code in HTML/PDF/EPUB/MOBI formats. I’m writing my third book with Asciidoc and am pretty happy with it.

4. Store all your drafts on GitHub even if you’re the only author of your book. GitHub also has a very nice feature called GitHib Pages that allows to publish your drafts online. For example, this is how my free book Java For Kids looks at GitHub pages. If you don’t want to make your drafts publicly available, either buy a private repository on GitHub
or create it for free on BitBucket.

P.S. Most likely, you’ll find grammar errors in the text of this blog. It’s OK. I need to push it out the door ASAP to get your feedback sooner. Please leave comments and I’ll fix the mistakes later.

P.S.S. I’ve stolen the time allocated for writing a chapter for my next book on Angular 2 and wrote this blog instead. Stupid me.

Software Development Today and 20 Years Ago

I enjoy the process of developing software, which includes many various activities. But learning and teaching new software are the two activities I enjoy the most. During my 30-year career I’ve been working as an independent contractor, taught countless training classes, prepared and read hundred of resumes, co-founded a couple of startups. You might be thinking that now a grouchy old programmer will start complaining that young software developers don’t know how to program? Don’t be. It’s all the way around.

The skills required today for getting a Software Developer job are different than in the nineties. I’m not even talking about programming languages that were popular then and now. The mere number of different languages, tools, frameworks, and platforms that must be present on a resume today is piling up. It’s more difficult to become a competitive software developer in the USA today than it was 20 years ago.

Back then, to get a job you’d need to know a programming language to develop UI and SQL for data persistence. Knowing stored procedures for a popular RDBMS like Oracle, Sybase, or MS SQL Server would help. This is it. The resume having Visual Basic plus MS SQL Server or PowerBuilder and Oracle would easily get you a job. Of course, you’d need to know them well. If you knew Unix shell programming (OMG!), you’d be getting several job offers in a heart beat.

Mid nineties. Do you know how to handle a Click Event on a button in Visual Basic and how to write an SQL statement that would find duplicates in a database table? You’re hired!

In the second part of the nineties people who knew how to spell COBOL and CICS – would be getting multiple offers because of that Y2K FUD.

The year 2000. The world survived the Y2K craze. Legions of musicians, cab drivers and civil engineers became software developers, and most of them were able to retain their well paying jobs. You know Java and EJB? Really? How much do you want to make an hour? $100. You got it.

Knowing HTML or JavaScript was not an asset – easy peasy and not serious.

The year 2014. Unless you have ten different technologies on your resume, do not even submit it to us. Got 9? Are you just out of college or something?

If you want to stay in business of software development, you need to continue studying. Non stop. Lots of different tools, frameworks, languages. I’ll give you an example. Take a look at the program of our 10-week online training “Modern Web Development for Java Developers”. It’s a very intensive training with lots of self studying. Just check the time lines of the first two lessons. It’s a lot to master even for programmers who already have working knowledge of Java.

Here’s a fragment from an email I’ve received from an programmer with 20 years experience who enrolled in one of there trainings:

I signed up for your Web Development for Java developers course. Looking at the outline. Should attendees do some preparations like install any software and play with it? The other day I went to an HTML5 meetup and was shocked – for more than an hour people were downloading and installing some software – Git, Node JS, Karma, Grunt, Bower. I got overwhelmed and left.

I feel your pain, buddy. I really do. Got to stay in good shape to compete with the young generation. These kids were born with smart phones in their hands and Facebook in their brains. They easily multi-task. They absorb new materials like sponges. You got years of industry experience behind your belt? This is nice, but they need people who feel comfortable programming for the Bring-Your-Own-Device world. It’s time to replace your Windows XP desktop with several modern devices and get back to school. Otherwise become a manager. Well, you need to get back to school in this case too.

Hiring in a restaurant

Recently a bunch of workers from our company went to a restaurant. One of our guys asked if he could bring a friend who was in town. Sure, why not.

The dinner went well, we were talking about various things from the quality of honey pepper vodka to what dependency injection brings (does it?) to the table. That evening we’ve injected moderate amounts of that vodka. Not much. To avoid dependency.

Some time passed by. We were looking to hire a new software developer. I recalled that friend of a friend and invited him for a tech interview. He did well, and at the end I’ve asked him, “Why do you want to join our company?” He answered, “Remember that dinner? Guys from your company were eating, drinking and talking software. The technical level of most of them was higher than anyone’s in my current team. For me this is an opportunity to learn.”

I hired the guy. Now I’m thinking, should we make such a “Bring a Friend” dinner a tradition in our company? It’s a lot cheaper than paying a recruiting agency. Actually, we never hired even a single person through a recruiting agency yet.

Technical books are getting thinner

While working the upcoming book on Web development, I keep stopping myself from writing too much. And this is what I want to talk to you about.  In the past, technical books were a lot fatter than today. A typical book on computer programming was a thousand pages long.  If the author(s) wanted to cover a set of related technologies (like J2EE or .Net) the book could span 1500 pages or more. People were used to read books because Google, Stack Overflow, Youtube and Vimeo were not invented yet.  Today, majority of software developers are googgling trying to find a code snippet to copy-paste, and the smaller part of the programmers watches video recordings from conferences.

I’m not sure if O’Reilly started this “Get Slim” movement, but recently I ran into their book, which was only 60 pages long. Want to be a published author? Easy. Write sixty pages and update your resume. This is yet another example of devaluation in action. The next step is to increase the font and add some comics-style illustration like in books for children.

I’ve just have submitted a 38-page chapter on selected HTML5 APIs, where I reviewed History API, Web Messaging, Web Workers, Offline Web applications, Web Storage, and IndexedDB.  Can these materials get a decent coverage in 38 pages? Yes, if the reader has some background in Web development and know how to self-study. Yes, because the code example are focused on the covered API as opposed to offering a 200-line code samples of which 180 lines is the author’s favorite set of utility functions, which he uses daily.

When you submit a proposal for the book, the publisher asks for the estimated number of pages.  A year ago we estimated that the book would have 600 pages. Most likely it’ll have a little more than  650 pages, which is a really thick book by today’s standards.  I also know that we’ll get several  reviews stating that the book doesn’t cover some of the topics in depth, which is perfectly fine. The main goal of a good technical book is to ignite the reader’s interest to a covered topic and give some   kick in the right direction so googling will become more educated and fruitful.

Do you read technical books  or it’s too old-fashioned? If you do, what’s your preferred book size?

Methodologies in Software and Medicine

When a person gets into an emergency room in a hospital, he or she gets treated by regular doctors, not geniuses. I believe, this is the goal of the modern medical science – to makes sure that lots of doctors are available to provide medical help to patients. I’d assume that ER personnel has some well defined and strict procedures as to what to do when a person shows up with specific symptoms.

That’s why, some patients may be wondering, “Why they put me through all these tests and kept me there for 5 hours instead of just giving me a pill to take care of my stomachache?” The answer is simple – there is a written and approved methodology that lists all the steps that must be taken. If something bad happens with the patient after applying all these steps, the medical personal is covered – they can’t get sued becase they were following the methodology.

Any methodology is a set of instructions.

Yesterday, I posted the following tweet, “All programming methodologies have the same goal: allow mediocre developers deliver something. Should we rather hire only good programmers?”  I got some angry replies to this obnoxious statement.  Should a hospital rather hire only medical geniuses to treat patients? Yes, if there would be enough geniuses and  the hospital had enough money to hire them.

Coming back to the enterprise software… The number of projects that need to be developed is large, not all of them should be even started and are doomed to fail anyway, but they have financing. Not all of the patients in the ER should even be there, but half of them are there because insurance pays for these visits. Can someone change this situation? I doubt it. Obamacare will result in the substantial increase of the numbers of mediocre doctors, while the gifted one will  try to find some ways to maintain their standards of livings and will become stock brockers, real estate agents, open the restaurants, etc. They will master new methodologies.

The software developers sticking to certain methodologies (TDD, SCRUM, popular frameworks, design patterns, ORM) have a safe and predictable career. How can you blame Joe if he attended every Friday’s standup meeting, wrote hundreds of unit tests, and all of his communications with the database were done via a de facto standard Hibernate ORM framework? Joe did everything as prescribed. If he got fired, there is an IT  shop across the street that need a person with a certificate of Srum Master.

Talking agile… people over processes… [Screaming…]  Then why people have to stand on their feet for half an hour? To me it looks like processes over people. Let’s do kanban. At least people will spend some time moving these colorful sticky notes on those dirty white boards. Why implementing  agile methodologies? To allow mediocre managers run projects.

Disclaimer. One of our projects pretends to use agile principles – it allocates work to sprints. We’ll implement this feature in sprint 87. Yeah, right. I’ll believe it when I see it.

I’m lucky to work for a small consulting firm, where over the years we were able to  build a team of talented programmers who know how to write code. They write code that works. It may not be easily readable by every programmer in the industry. I know that some luminaries believe that the code should be written for other people, and not computers. I have my reservations. The code should be efficient. I’m not saying that we need to generate a spagetti code and bring back the Go To operator, but the code should work well.

Recently I’ve learned, that in one large outsourcing consultancy to become a Software Engineer of Level 1 you’d have to pass a test that requires  to write a certain amount of code in a given time. What is that? Why not just giving extra bonuses for software developers who can speed type? In Cobol times, one of the first questions head hunters were asking was “How many lines of code have you written?” But I can’t recall a question “How many lines of code can you write in one hour?”

Again, not everyone can have a luxury to build a team of highly skilled software developers.  I’m grateful that I’m one of these lucky people.  Sorry for writing this blog.

How to Present new Software Releases

If you run a product company, you have to release new versions of your software. In the USA the mantra is “Never undermine your product”. Because of that, the most popular words in describing the software produced by your company are great, fabulous, fantastic, or simple the best. Important: never speak negative of your software. 

Say, you’re releasing the version N of your software product. Over the last six months your software engineers were working long ours trying to fix 159 critical bugs reported in Jira and 573 non-critical ones. Ten new features were added in this version, and finally Release N was pushed out the doors.

Your firm runs an annual conference for developers, and you are delivering a keynote about the new release N. This is how you should open the keynote (remember the mantra!).


“Hello guys,

Thank you for your continuous support of our Software. The version N-1 of our Software was fabulous. We are the leader in this market. But we wouldn’t be who we are if we wouldn’t be always trying to find new solutions and make our Software even better. The Release N is simply the best in this sector! Das ist fantastisch! 

The performance of the Software N-1 was always beating the competition. But we were able to tripple the speed of network communication in version N.  The UI in version N is the richest UI ever – we doubled the number of our UI components.” If you have time left, do a very light intro to the list of new features introduced in N. This will discourage some smarty pants from the audience from embarrassing you by asking geeky questions like “Have you resolved that showstopper bug in your rendering engine that crashed our application three times a day?” But if someone will ask you a question showing that this guy knows your software better than you, gust say politely, “We can take it offline. Just grab me in the corridor after the talk.” I can guarantee, that after giving such an answer no one will grab you anywhere.

Everyone knows that release N will reveal a bunch of new issues and the release N+1 will fix them and add something extra. But who cares what’s left behind? Look forward, move ahead, inflate your importance or else…

P.S. If you’ll ever hear me presenting a new software product of our company in such a manner, do not buy it from me. Most likely this software is full of crap as well as the presenter.

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.

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.