8

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.

14
  • 8
    I will answer after you come over to my place for a drink. Oh, and bring some wax with you.
    – Job
    Jun 5, 2011 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 Jun 5, 2011 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".
    – snakehiss
    Jun 5, 2011 at 23:36
  • 19
    20 years of experience in Java? ORLY?!?
    – SK-logic
    Jun 6, 2011 at 9:52
  • 8
    That'd be 1 year of Java experience, repeated 19 times... Jun 6, 2011 at 21:37

18 Answers 18

54

I would almost say it's the opposite....

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.

9
  • 6
    +1, Also compilers change over time, while the no-longer-needed-hacks remain in their place.
    – Job
    Jun 5, 2011 at 22:53
  • Obtuse? Do you mean obscure?
    – webbiedave
    Jun 6, 2011 at 4:05
  • 9
    @Bobby: I've run into this type of coding myself. I've heard it described as a stupid use of cleverness.
    – webbiedave
    Jun 6, 2011 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. Jun 6, 2011 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. Jun 9, 2011 at 20:32
42

programmers with more experience know more things

they are not secrets

sounds like he's trying to sell you something!

1
  • 21
    +1 for "he's trying to sell you something!" he most certainly is !
    – Chani
    Jun 6, 2011 at 5:09
29

"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.

5
  • 8
    Don't forget the StackExchange equivalent Proof By Reputation Score Jun 6, 2011 at 11:01
  • +1 for an attitude I like. Jun 6, 2011 at 14:11
  • Arguments from an individual's own authority (claiming it for themselves) are, as you said, usually hollow. However, arguments from the authority of an individual with expertise in the subject are likely to be valid. They're not logically provable, which is why they're disparaged in your links, but it's certainly respectable. Jun 9, 2011 at 20:35
  • 3
    @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." Jun 9, 2011 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
    – RobD
    Mar 27, 2014 at 14:30
25

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.

0
22

The only secrets that I am aware of are:

  • Nothing is as easy as it looks. What you don't see are all my failed attempts.
  • You must never stop learning.
  • There is no substitute for hard good work.
5
  • I agree them with you. But he was talking some secrets like about best practices, patterns ..etc
    – Freshblood
    Jun 5, 2011 at 22:32
  • How do you know something is the best,without first trying out the rest?? I'm with barrem23 on this one. +1.
    – lightsong
    Jun 6, 2011 at 5:43
  • 1
    true, for every 10 good lines of code you write down and committed, there are probably 90 lines of code you have written and deleted to arrive to that 10 line solutions.
    – Lie Ryan
    Jun 6, 2011 at 6:03
  • @abhiii: How do you know? Asking here (or on SO) is a good start. Jun 6, 2011 at 10:52
  • I take issue with that last aphorism. Say a programmer, looking to recognize all characters other than the lowercase 'a', spends a day typing out a character class that contains every other character they can find on their keyboard. This is hard work. The next day, a senior programmer, yawning, replaces it with four characters: [^a] - not only does this make the expression faster, it also includes a number of extended / Unicode characters the original missed. I say that, at least when it comes to programming, hard work is meaningless. There is no substitute for good work. Jun 9, 2011 at 18:34
9

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>

2
  • Hey! MY code does not suck! Oh, wait. Sorry. Got that negative wrong. Yeah, you're right. All code sucks. The only difference lies in the degree of suction. This ranges from galactic black holes to broken vacuum cleaners. Jun 6, 2011 at 3:11
  • 2
    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. Jun 6, 2011 at 17:42
9

I've got 50 years experience. I've learned a lot of things that younger programmers haven't yet. I'm perfectly willing to share them, and I try to, in many ways.

Learning is something you have to want to do.

I often hear that maintainability is really important, and I agree completely. However, it doesn't come for free. It may require more or less of a learning curve on the part of the maintainer.

A programmer fresh with a Master's degree in Computer Science would look at my code and say it's unmaintainable and full of secrets. In fact, he or she is simply not done learning new things.

Pilots have a saying, when you pass the required tests and are handed your pilot's "ticket". They say it is a License To Learn.

Education doesn't stop when you get a diploma. It's only begun.

2
  • 2
    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". Jun 9, 2011 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. Jun 10, 2011 at 4:47
7

Knowing little tiny hidden secrets of certain programming languages or frameworks has little to none practical value.

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.

2
  • 3
    +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.
    – user16764
    Jun 5, 2011 at 22:32
  • The fact that C++ has corner cases and undefined behavior doesn't bother me much, because I don't get close to those things anyway. Knowing these things does help in debugging badly written code, though. Jun 6, 2011 at 14:12
5

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.

4

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, ...

In other words, the secret is experience.

3

Obviously, someone with 20 years of experience will have more, well, experience than someone with only 2 years. But there's no secrets -- what would be the point?

(Of course, someone trying to keep a secret would say that...)

1

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.

1

Everything that only a few know can be considered a secret.

Everything that we know today was once discovered.

So everything once was a secret.

Some knowledge spreads fast and some spreads slowly.

Some programmers never discover anything themselves(, but might apply secrets of others very successfully).

Some programmers (e.g. John Carmack, Ken Perlin, Donald Knuth) seem to stumble over a new secret every day.

So yes, there are programmers who know some secrets that we others don't know ... yet.

1

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?

1

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.

0

There ARE no small secrets. Only complicated code...eventually churned into simplified efficient code.

0

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.

0

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..

And then Google. The biggest secret of all up to date.

2
  • The guild will come after you for sharing the secret of Google with the world. The first rule of the guild is do not talk about Google.
    – Ramhound
    Oct 20, 2011 at 16:18
  • Well, IF the guild will come after me, it will be rather for mentioning vi in vain..
    – John Donn
    Oct 21, 2011 at 9:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.