Shit old programmers ask

It seems like whenever you approach an old programmer and ask a question, they immediately fire back a question. It's not that they are trying to poke holes in your logic, in most cases, they are trying to quickly get some insight into what you are really asking.

These are the questions I seem to ask every time someone asks me a programming question.

Wait, what are you trying to do?

We understand. We see that you have the perfect Rube Goldberg Machine designed in your mind. You press the button, the balloon pops, it frightens the chicken into laying an egg, and so on. Finally, the monkey selects a random ping pong ball. An AI system reads the number from the ball. We like that you have put so much thought into designing such a perfect system, but please understand some things: that squirrel that runs on the wheel? He might die one day, and that bowling ball company you want to build? You can just buy a bowling ball.

At the end of the day, we just see that you are trying to pick a random number, and there are a million ways to do that in one line. If you get super interested in generating random numbers, and want to do it on our own, that's another conversation. Just use the library method for now, and we can talk about how the algorithms work (there are neither squirrels nor monkeys) later.

Why do you want to do that?

When we hear a question like, "How do you take a hash that has arrays of hashes as keys and extract the color of pet dog from every i th element of every j th array?" The first question will always be "Why do you want to do that?"

We're not trying to be smug or uppity, we just can sense there is something else going on. When we hear very specific needs wrapped in very general idea, a million red flags go up. What we're really asking you to do is explain the problem in the the realm of the problem. Something like: How would you go about finding the total and longest amount of free time for one machine in a week, where I have this data on each machine.

We're really just asking specifically which problem you are solving with which data.

You should probably write a test for that.

We have dropped what we're doing to help you troubleshoot something tricky. In twenty minutes, you have, via the browser and endless clicking, created two test cases that we now have to dig through a mass of log files to understand. When I suggest we just write a test, your reply is usually "this is just super trivial." But it's not. We just burned 2/3 of a man hour on this right now, plus however long you have been messing with it. I could go on and on about testing, but suffice it to say that you should test your intention at all times.

The simple act of writing the test for this would probably have shown you right where the issue was, and kept my hours off your project. Us old guys would be totally happy to talk about testing during lunch or break or any other time off the clock. If we keep showing up as hours on your project, someone is going to be upset.

What is the error that you are getting?

I am going to let you in on a secret. The first thing I am going to do is paste whatever you send me into google. If the answer pops up in one of the first three results, I am gonna be a little bothered. I was probably in the middle of a flow, and now, I have stopped for something you really could have done.

That being said, I would guess that 50% of the time, the error message is cryptic at best. After looking at this stuff for a bazillion years, I can probably give you insight into how to proceed, but it's gonna be a team effort to figure it out. Don't be surprised if I come back to you in six months, and ask, "Remember that time we got the XYZABC error?"

Can I talk something through with you?

Sometimes, as a programmer, you get stuck. You probably already know the solution, but the web in your mind is so heavy and complex, it's blocking the simplicity from getting through. Once you have done this for a long time, you know all the symptoms, and you are not shy about reaching out for help. At first, it takes a bit of courage to tell someone else "I am lost, and I don't understand." If the person you are asking is honest, they will know exactly how you feel. If not, their opinion is not that important.

Old programmers know that the simple act of explaining your confusion to someone else, in most all cases, immediately turns a light bulb on in your brain. Even if it's not that case, a good deal of times, that person will have either faced that challenge, or knows someone to go to for help.

Don't be afraid of not understanding. Don't be afraid to ask for help.

Those are just the few that came to mind at lunch today. I am sure I will amend this list or write a part 2 at some point.