I will not bother you with details of my discussion so I will present it in the form of a short instance.

A java guy has been following articles and publications of a famous programmer (a kind of Martin Fowler of my country). He says that he is sharing some secrets which other famous programmers don't share.

I never believe that there are some secrets like wizards in the programming area. But some programmers who are not good yet in this area think that other famous programmers are success because they know some secrets that we don't.

I totally disagree with this and I discussed it with someone and finally he said to me you are 2 years in this area and he (java guy) is 20 years professional programmer so he knows better than you.

I wanted to be sure that I am not wrong. That's why I wanted to know this.

closed as not constructive by Mark Trapp Nov 15 '11 at 17:25

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

8

I will answer after you come over to my place for a drink. Oh, and bring some wax with you.
–
JobJun 5 '11 at 22:09

58

We know of that guy. Stay away from him or you may get yourself into trouble. The secrets of our sacred art must be kept hidden at all costs! The Guild of Veteran Programmers will punish that traitor soon! :-p
–
Péter TörökJun 5 '11 at 22:52

15

The big secret to good programming is to "write the smallest amount of clear code with a minimum of complexity to adequately solve the problem".
–
dietbuddhaJun 5 '11 at 23:36

18 Answers
18

I've worked with people who liked being tricky for whatever reason. Granted, they actually were pretty good programmers - when taken in a vacuum - but the code they produced was often quite obtuse and difficult to maintain by others. There is no point doing something clever that saves a few keystrokes, when two years later someone maintaining the code is going to waste a day when they get stumped by the trick.

In fact, if I had to nominate one most important thing that I've learned in my ten years of commercial experience as a programmer - it's that maintainability is important. It reins supreme far above knowing some obscure hacks and tricks which might come in handy in rare situations, but which will almost certainly make the codebase more difficult to maintain in the long term.

To be honest, I would go as far as to say that all coding should be done such that any new graduate with relatively basic core knowledge in the given language/platform should be able to pick it up and work with it. If it's so tricky and obscure that you need someone with 20 years experience in the language/platform who knows every little internal trick, then the project is in dire technical debt.

+1, Also compilers change over time, while the no-longer-needed-hacks remain in their place.
–
JobJun 5 '11 at 22:53

9

@Bobby: I've run into this type of coding myself. I've heard it described as a stupid use of cleverness.
–
webbiedaveJun 6 '11 at 7:02

1

@Kevin - I'm not so sure. Something a recent grad could understand is not the same thing as something the recent grad could actually write. Excellent code should be that easy to understand, given that the grad has a basic knowledge of the framework and using a debugger. Most decent code is pretty easy to understand, while it is usually the business logic that can be a challenge to learn for a recent grad. Most likely this person has zero domain knowledge, which can be tough to catch up on.
–
Morgan HerlockerJun 6 '11 at 17:28

2

@Kevin: A master karateka uses only a handful of basic moves, but has learned how to apply those in endless variety. A master carpenter uses only a handful of chosen tools, but has learned to apply those in perfect combination. The more experience I gain, the more I think it's the same in programming. Not that you don't sometimes need something esoteric, just that it's very rarely the case.
–
Joeri SebrechtsJun 9 '11 at 20:32

"finally he said to me you are 2 years in this area and he (java guy) is 20 years professional programmer so he knows better than you."

<rant>

I first ran into crap like this over 30 years ago. It pissed me off then and pisses me off even more now. It's called Argument from Authority (AKA Proof by Authority) and it is pure, unadulterated bullsh*t. Every person I have met who has who tried to claim this for themselves has had a serious problem with self esteem ... and often knew far less about the subject than they pretended to know.

I have personally known several scary-smart programmers who were still in high school and had been coding for only a year or two. Just 2 examples: the original forum system was written in 1973 by a 15-year old, and the very first implementation of multi-user instant messaging was written in 1974 by a 13-year-old who drank milk while the other engineers were having a beer on Friday afternoon.

I also know quite a few dinosaurs who haven't picked up a new technology in 10 or 15 years. Many of them will admit to not tracking what's happening in present-time, but there are a few who see this as a badge of honor. It's not.

</rant>

Having got that out of my system, I would like expand on a point made in the answers of @Bobby Tables and @Developer Art: using "secrets," writing "clever code," or doing anything in the code that is a "proof" of how obscure you can make something is wrong. Period. It is the act of an immature, self-absorbed person who does not have the best interests of the project/company in mind. They are laying maintenance landmines that will go off some time in the future, probably after they have moved on to other victims employers.

The opposite of "clever" is to write clear, concise code that uses the programming language well; uses consistent naming standards; appropriate end-of-line comments; good block comments to explain major sections; is documented (with examples where appropriate); and tested. That's what a real professional programmer delivers.

And when they are done, they turn around and mentor the next generation of professional programmers.

@Kevin: I'm not saying that a person with more (real) experience isn't more likely to be right, but that's simply a probability. If we were dealing with a soft science I might be more ready to concede the point, but we are dealing with one of the harder Hard Sciences there is. That means I don't want an opinion or a "trust me," I want cold, hard, provable facts. Many years ago I found a fairly serious bug in Sun's C compiler. When I tried to report it, a Sun "expert" tried to blow me off with, "That kind of bug could never get through our QA." I told him, "Talk to the error message."
–
Peter RowellJun 9 '11 at 22:37

1

The more experience I get and the more I learn the more I realise how much I don't know and the more humble I become. I am now completely certain that I cannot write Ehlo Wordl correctly
–
RobDMar 27 '14 at 14:30

I'm not sure how anyone can speak to another person's hypothetical knowledge, but my experience is that there aren't any "secrets" to computer programming. Indeed, it is a domain almost defined by openness and knowledge sharing. Some of the most complex projects (those that would arguably most benefit from such "secrets") are open source, like the linux kernel.

I find the idea that programmers are secretly hoarding special techniques to be absurd but it's quite difficult to prove a negative – especially when it's purely hypothetical.

I do know of one secret that younger programmers don't tend to know or accept. Once one is advanced enough to understand this, he's usually figured it out on his own.

<TheSecret>All code sucks. Especially yours. Mine does, too. The code of all the genius programmers of the world --- yeah, it sucks, too. Accept it and just get the job done as best you can.</TheSecret>

When I was first taught about testing, the professor made us write down as many tests we could think of for a basic function that calculated the area of a triangle given the length of 3 sides as parameters. I was certain I had come up with a complete test coverage solution with my ~11 tests...until she showed the actual number of valid tests closer to ~111. I realized that even my trivial code would never be flawless.
–
Morgan HerlockerJun 6 '11 at 17:42

If a newcomer to your code with a reasonable amount of basic understanding (which most people would qualify a Master's in CS to be) says that your code is unmaintainable, it is. Maintainability is the measure of understanding required from a base of zero. All code is "maintainable" if you define it to mean "anything that can be understood, given world enough and time".
–
Stuart P. BentleyJun 9 '11 at 18:10

1

@Stuart: If I can just give an example. In 1985 I stumbled on the method of differential execution. It is a way of making a domain-specific-language where the domain is complex user interfaces. It saves roughly an order of magnitude of source code, and once you learn how it works, most maintenance (code changes in response to changed requirements) are very simple source code edits. That's the sort of thing I mean. The maintainability comes at the price of a learning curve.
–
Mike DunlaveyJun 10 '11 at 4:47

Most of the practical software development doesn't encounter these hidden features in their practice. Even more, one of the best practices suggests you deliberately avoid venturing into hidden areas of the technologies you use because it makes the code less maintainable and more prone to errors since most programmers won't know these "secrets".

Instead of spending/wasting (pick one) time on learning the secrets of one specific technology it is generally better to expand one's knowledge range and learn adjacent tools or even better improve your non-programming skills or learn more of the business you're in.

With the speed of the change in our field deep investment into a specific tool is not worth it - the knowledge will be deprecated soon.

Now, only if you position yourself as a technology expert and intend to be offering your consulting services in this specific field does it make sense to invest in deep. Otherwise it's wasted effort.

+1 for pointing out that "secrets" are secret for a reason. A good example would be the "undocumented" Windows API, the use of which makes your applications unmaintainable.
–
user16764Jun 5 '11 at 22:32

You are being sold a bill of goods here. Someone is trying to employ the concept of Mysterious Secrets™ that make you an Elite Programmer™ with an eye toward getting you to pay for those Mysterious Secrets™. The next step is someone offering to teach you those Mysterious Secrets™ in the form of videos or speeches or podcasts or badly-printed books for the low, low price of only <insert whatever the salesman thinks you'll be willing to pay>.

How can I be sure of this? I've been programming since the '70s and I know a metric tonne more programming languages than just Java. I've seen programming (professionally and scholastically) from the smallest of the small (embedded systems with hundreds of bytes – that's bytes – of RAM) up to huge pieces of Big Iron™.

There is a secret to being a good programmer and only one: you need to work at improving yourself constantly. Anybody who tells you otherwise is a liar and/or a fool.

The only secret that is not known by young programmers is: programmers are not as smart as they think.

Once you know that, you stop writing code that you won't understand next month, you start to appreciate version control, you don't fix code that already works, you document your code, you don't interpret specification, you don't code features that might be useful someday in the future, you don't reject legacy code, ...

While experience matters, we can learn from the experiences of others. I just finished reading "The Clean Coder" where Robert C Martin (Uncle Bob) shares mistakes he has made and lessons he has learned. Many of which are listed in answers here like keep learning.

Knowledge alone isn't power, I'll grant you that. However, someone may have developed their skills further than you which may mean that they have tips and strategies that may help you advance yourself. Note that there are a couple of "may" in the last sentence as it isn't a certainty that these will move you along really. Thus, there is the potential for this to be nothing new or shocking for you.

At the same time, there are various practices and strategies that at one time may have seemed radical though today we take these for granted. Source control, continuous integration, and unit testing were all new at some point, right?

It is possible you and most people answering this question are focusing entirely too much on the word 'secret'.

If we take the 'hidden' part out of it, then yes, it is entirely possible that this famous programmer has some useful tips and tricks or knowledge won through experience that would benefit you in some way. I'm talking about knowledge like you would find in classic SE or CS books, like Rapid Development or The Pragmatic Programmer. This combined with hard work can absolutely help.

So in that sense the famous successful programmer may be in possession of knowledge that others just don't have yet.

But there's not any kind of secret recipes that will turn a 'programmer not so good in this area' to a famous one with lots of success.

The secret lies with the type of problem , area of problem and how you solve it. Forexample i wrote a php programme to open a file and read its data and convert the data into xml and then i used that xml to present data into different html elements i.e. option box etc. After 1 year we had a new junior programmer to join the team and he was good in algorithms so he solved the problem mathematically which did make the code look difficult with shift lefts and dividing the arrays etc.etc. but the execution time was reduced upto 40% of what i wrote . His approach to write the php statements surprised me So i believe there are certain tricks which do exist not the secrets; one more thing is how many number of alternatives you can think in your mind. So the secret is actually not a secret that is bascailly experience one posses by solving or going thorugh different problems , designs , architects etc.etc.

Sorry if I am missing something, but I could not find this above, at least not explicitly stated.

The secret is actually using the right tools for the job. In fact it is the tools that old programmers cherish and do not disclose so easily. They will talk to you about your CONCRETE mistakes, but will rarely suggest which tool might help you to avoid them.
Their tools are one of the main secrets of their productivity.

Giving just an example,
one can memorize a 600-page book on web services, understand the intricacies of
WSDL specification (I tried it myself once.. to understand the intricacies), and still
not be able to understand what goes wrong with the API he uses when he tries to
make a call to an existing web service..

On the other hand, one may have little knowledge of the spec (but a clear general idea)
and use Wireshark..

One can remember all C++ (oh my..) and still not understand what goes wrong with
his code written with vi, and compiled with gcc (no warnings..). But a graphical IDE with a debugger might help..