Is a senior programmers advice about always using books a good idea?

Question

I am a junior developer and have only been in the industry for 5 years. At my current company there is a senior let's call him Infestus. Occasionally I am being given opportunity to shine and do something completely brand new from scratch.

One of the most recent examples was that I had to make a singleton in the multithreaded application. I have decided to use this method. As soon as Infestus saw it, he quickly proceeded to call me stupid and told me to use this approach. Upon asking him why he just brushed it off as this is better and that's how this and this book about Java says it is better.

And it is a common pattern: whenever I get a chance to do something new, I quickly get shot down by Infestus and the only reasoning why his method is better is because those books were written by famous programmers. He is always trying to give me books to read so that I may "learn" which ways to program.

I have only been programming for money for 5 years, but is it always a good idea to just blindly follow the book on best ways for solving a problem, or should I try experimenting every now and then? The constant barrage of complaints from the Infestus is starting to cause me to never try anything new and follow examples in books.

EDIT: I am utterly lost. Yes I know that following anything blindly is a bad idea. But this godlike programmer Infestus who seems to know a lot, tells me that the only way to program properly is by reading books and following everything down to a T. All the rules he imposes are the ones written in books, so I am just wondering if books are the only correct way.

EDIT2: Infestus is not my boss. He is just one of senior developers in charge of reviewing the code. And most of his comments after reviews consist of book names where such and such method is wrong.

Answer 1

You are going to run into programmers like this your entire career. There is nothing wrong with experimentation and learning on your own. Sure books are great. Many times the examples work in a clean environment, but if you are developer for another company there is no such thing as a clean (without interference from others) environment.

It's always nice to know how to do things the "right" way, but opinions change year to year. So learn what you can. Take what you can from the senior developer, blend it with your knowledge that you learn on your own. Eventually, you will be a senior developer and will be taking from these experiences and teaching junior devs.

Just don't be a jerk about it.

Answer 2

Did he really call you stupid, or did he just disparage the code? Calling anything stupid is tactless, but that doesn't invalidate the suggestion. I think Infestus has made a valuable suggestion, and in the future you should consider his suggestions seriously. He seems to do a lot of reading, and at least in this case his opinion is well-informed. Synchronization is both expensive and tricky. His recommended implementation is more efficient and simpler than yours, and is guaranteed to work.

He is always trying to give me books to read so that I may "learn" which ways to program.

That is kind of him. He is actively trying to help you, but you seem to be letting your ego get in the way. Do not take criticism of your code personally. Code is cheap to produce and easy to change. If someone shows you a simpler way of doing something, thank them.

And yes, reading will make you a much better programmer. All the experts I have known read extensively. If you are not reading much, then you are mediocre at best, and in another five years you may find that you are no longer marketable.

Answer 3

Reading a book shouldn't be blind: the author should try to convince you of the merits of his/her approach as he presents it. It's reasonable for your senior to point you to a book explaining his preferred approach, rather than asking him to explain it himself: though he should be able to explain the benefits of his preferences without relying on the book, it's also a duplication of effort that the book's author has already made.

So, read the book, see what the book's author says, and if it confuses you, or you'd like to confirm your understanding, or you don't agree, then talk to your senior about it, but now you'll be able to have a more productive discussion.

Answer 4

There are three key elements to any healthy relationship. Communication, honesty and trust. That counts for all relationships, even working relationships. You should be talking to your supervisor about these concerns.

If you don't understand his reasons for advocating a certain design, then tell him that. Tell him that you haven't read the book, and that you'd like to understand why his way of doing it is better. The key is that you should be trying to understand his way of doing things.

I think you should also treat this person with more respect. In your head, you're calling him derogatory names, and criticizing his approach to what you think of as "learning". Watch out for that. On the other hand, you did say he called you stupid. That's not cool, and you should tell him that's not cool to call someone stupid.

Ideas can be stupid. We all make mistakes and miss things, even the senior guys. When there's a flaw in a design, the best question to ask is "Why are you doing it this way? Won't it break in situation X,Y,Z? Won't design B be better?"

Keep in mind that you're working on this software with other people. That's a hard skill to learn. It doesn't matter that you're not writing anything from scratch, there is always room to shine by making your code the best code you can.

And "best" very often means readable and understandable. We programmers spend a lot of time reading other people's code. If that code is clear and readable, then that makes the code really valuable. One of the ways we learn to write great code is by reading lots of good code. You very often find very good code in books. So reading one or two good programming books will likely make you a better programmer.

Answer 5

In the company where you work, it probably is. This is what they require you to do.

This engineer Infestus does a very poor job educating junior developers by telling them "this is written in the book, and that's why". He's not a preacher, he's an engineer, and he should be able to break it down and present the concepts so that juniors would be able to learn from his experience.

I would encourage you to speak to knowledgeable developers in your company, ask them questions about the pros and cons of different programming techniques etc. This along with reading books and blogs (I would recommend Joel on Software - just Google it, it's a must) should give you a better understanding.

Answer 6

IMHO, there are 2 aspects here, which you should deal with separately:

• The fact that the guy is being a jerk, calling you names and such simply because he can (he's senior, you're not, if either of you complains about the other one, he'll get the benefit of the doubt) is simply bully-like behavior, and just bad.

Try not to stoop to his level with this. Don't try to bully him back or "tell on him" to the boss or anything. Do your best to ignore this aspect of his behavior, keeping in mind that it becomes too extreme (i.e. if it affects your productivity and such) you should do something about it.

• The fact that he's telling you that your code is bad (and how to do it proper). Honestly from what you describe, ignoring the guy's tone, this aspect of his behavior is not that bad. You learn things a lot faster and get to see them in the proper context when you have someone more experienced correcting you and telling you not only what you did wrong, but also how to do it right (as compared to just learning them all by yourself from personal trial/error experiments and the like).

Many a time I've had someone correct what I initially thought was "my perfect code" and just got upset that the guy was telling me what to do only to later realize that he was right all along, my version was bad, his was good, and thank God he saw that! :) So I've learned to tone down my initial impulses of "hey, u no tell me what to do, mista!" and instead, each time someone corrects me I first really, objectively, re-check my code, then check his, and make sure he's not really right and it's me who's doing the blunder. If it was my fault, I thank him from the help, and make sure I really understand how his solution works (rather than just copy/pasting it in).

And hey, sometimes I do find that the offered correction was in fact worse than what I initially did, at which point I try talking all this out with the other guy. Honestly, I've noticed that nothing gains the others' respect for you faster than when they see that you can accept being corrected when you've made a mistake, but at the same time, are not afraid to say you're the one who's right when you think it's so, given that you can immediately prove that you base your affirmation on some actual research, and not just ego.

On this point, I think you should really try and talk to the guy about what he proposes, and what you propose and so forth. Show him what you think, how you got to a particular solution, and why you think it's better than his (when you honestly and objectively think it is). Or, if you find out that his proposition is better than yours, tell him so, express your appreciation for the help. This may rebuild some burned bridges.

Answer 7

Experiment on your own and learn all that you can. After you read enough books, you're going to discover that there are multiple books on particular subjects and they may contradict one another. Try the one you think is best and try both if you have the time or want to compare/contrast.

Dealing with your boss is an entirely different subject and approach. If I wanted someone to do something the exact way it was in a book, I'd tell them. That's just me because I don't associate with mind readers. Your boss makes this a habit, just ask if he recommends any books or references when you get a new project.

Whatever you do, don't stop working on new projects. I know it is easy for all of us to give tips on how to deal with this situation and they may or may not work, but you're the one who has to live with it and suffer the negativity. You're going to get better, but that usually comes from writing more code on new things, learning from the sucesses and failures.

Answer 8

Following books blindly is a bad idea, but there's a difference between following a book exactly and following it blindly.

When you're trying to understand stuff in a book, it generally is appropriate to follow it exactly at first, while you're getting a feel for what it's trying to teach you. Odds are that you still won't understand everything when you're done -that's how things like this usually go- but following the book exactly at first will give you something to experiment with, as you try to understand your questions. Odds are again good that you'll find ways that you disagree with what's in the book, but you will have an understanding of the issues that the book was trying to address, so that when the time comes to write your own code, you can address them in your own way (or maybe their way, at least in part) rather than just leaving those issues to bite you later.

One other thing which isn't inherently specific to Java, but is nevertheless especially common in that community. I think I can guess which books you're talking about, and they form a major part of the lexicon of the Java community. Understanding them, and the ways they describe things, will help immensely when you need to understand other Java code that you find. That's a valuable skill in its own right.

Answer 9

Reading books and blog posts is very helpful in programming. There are some books, which all developers should read.

However books are not the only source to learn different programming concepts and technologies. Nowadays on-demand video based training is getting very popular. You can check Pluralsight, which provides high quality training to professionals.

In fact, if you read only books that is not going to help either. Besides reading there are other thing that we need to do as well. You can find more details here.

Answer 10

You should ask him what in particular is wrong with your method. If he is unable to answer it clearly, you might be pretty sure that it is just a common guy who likes to feel superior.

Answer 11

The thing about books is that they - mostly - pass through revisions, which have a better chance to spot bad practices and misconceptions. Also, the "big names" are experienced people who rely on being good to earn extra money selling books, thus, there are some minimal quality assurances about what they say.

That said, reading books, papers, and other sources is a good way to grow as a professional, of course, when confirmed by practice. So, it's good for you to read those books (even those recommended by Infestus). However, the books must mainly enlarge your comprehension on the subject, since there will almost always be other ways to solve the same problem.

About your "go by myself" approach, the point is: can you sustain your point of view? How do you prove your solution to be better than any other? Some times you can devise bright solutions by your own, but, when compared to other known solutions, you must to be able to argue the reason why yours is better, since the others have at their favor, at least, the use cases. Then, be creative and thoughtful, but most importantly, be effective.

If I were, you I'd read those books. That will help you by giving you more arguments, and, at the same time, you may find that Infestus - maybe - is wrongly taking those books as arguments, and he wasn't spotted yet because nobody knows the content of those books. Or you may find that he actually k

Answer 12

My experience is that when concerned about programming subject matter, the quality and presentation of information with adequate explanations in books is a magnitude better then when searching for same subject information on the internet. Internet often lacks proper explanation, context and quality.

The quantity of said information on the internet is higher.

So my general strategy is to learn from books to get a deeper understanding and after that learn from the internet to get exposed to different implmentations and widen my experience.(and often see how not to do stuff).

Answer 13

I would research the merits of each approach and come to your own judgement. If you think your approach is better, discuss it with Infestus until one of you convinces the other. If you can't reach an agreement, you could either ask for a second opinion or just accept Infestus's approach, depending on how strongly you feel about it.

In the case of singletons, one argument you could make against the enum approach is that enums can't extend classes. I often write code like this:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

This can't be done with enums. Since the enum approach doesn't work in all cases, you could argue that for the sake of consistency, it should be avoided even when there's no need for an extends clause.

Some other arguments that could be made against using enums:

• it's a hack - it's using enums for something they weren't intended for
• it's confusing to readers who haven't seen it before

Answer 14

I heavily rely on books as a source of knowledge - these are excellent foundations and I think Infestus is right in that you should be consuming significant quantities of books in your spare time as they really accelerate your skills. Books are not the only source of information though that I think you should be consuming - attend your local user group, get the relevant technology newsletters delivered to your inbox, read blogs.

I disagree however with the assertion that because it is written a certain way in a book, that it is the way it must be done. Yes books provide great advice, and they are written by experts, and peer reviewed by experts, but having been involved in a comparitively simple book I can tell you it typically takes at least two years start to finish to write, edit and release a book. The pace of change in technology is rapid and the advice of two years ago may no longer be correct advice for today. Generic principals often stand the test of time, but optimising a specific activity can be invalidated with a new bit of hardware or a new software release.

The suggestion of asking Infestus to go through suggestions with you is an excellent one - go away, read everything, and come back with a bunch of a thoughtful questions you've already tried to answer/solve for yourself along with your supporting evidence for your method.

There were questions about whether after 5 years why you were still a junior. For me, the key measure of whether someone is a junior is not years of experience but how much they require spoon feeding. I expect a mid-level developer to be relatively self-sufficient, a thoughtful consumer of knowledge sources who can act upon it and extend it to their situation. They should also be at the stage where they can start teaching juniors because they have a firm understanding of their topic so that they can explain things clearly. The other core competency is confidence - if you've done the work, read the stuff, and produced something decent, don't be afraid to stand up for it in a court of debate as a junior requires validation, a developer requests consensus.

Answer 15

Setting aside workplace manners, setting aside the reality of a mentor role that senior developers have, setting aside your own desire to explore, setting aside insulting behavior, and setting aside fetishes for books ...

The purposes of a code review in a team are 1) to validate code and 2) to ensure the person writing the code understands the meaning behind code improvement. It's not the place to say "change this because Martin Fowler said so in the GoF book". However, it is the place to say "change this because [brief explanation]; there is more detail discussing this in the GoF book".

If your senior developer is not, at least simply and subtly, providing an explanation for a change, and insisting on using the verbiage of "because of [book]", he is being a bit of a smartass and a jerk. How do you deal with it? Mention it in a team meeting, verbally, and ask for your teammates to provide a statement or two briefly explaining the advantage or necessity of the change, along with that helpful book reference. Be sure to thank him for the book reference.

Face it, your goal is to appreciate the change suggestion and to not be demotivated for your task or your job. Tell him that. "I would appreciate the change suggestion more if you could briefly describe the advantage or necessity of the change when you review my code; as it is I am finding your book references alone to be a bit demotivating."

If he continues to refuse to provide a simple explanation with his book references, if you can provide another book or resource of equally or greater notoriety in the industry with a different opinion and it matches your scenario, you might be able to add your own book reference in your review comment in consideration of retaining the original code. Do this enough times, he might back down. Be very careful that the counter-argument is right and significantly more important; it's okay to let a senior developer be wrong and still have his way, this is something I've learned and keep having to learn.

Answer 16

I'd say that learning programming from books only is impossible, but they good ones will provide you with a huge boost. It's like karate - you won't get black belt only reading about it ;) I believe that in this partucular case Mr. Infestus was refering to "Effective Java" by Joshua Bloch. It's really a great book about Java development and you should definitely read it if you havent already.