What have you tried?

The strawberries taste like strawberries. The snozberries taste like snozberries. This is the Music Makers podcast where I read things out loud to you and then offer my unqualified opinions on them. What Have You Tried? By Matt Gemmell.

If you're a developer and you're about to ask another developer a technical question on a forum, via email, on a chat channel, or in person, you'd better be ready to answer the question. What have you tried? This, of course, isn't specific to software developers, but that's my field, and it's thus the area in which I'm most familiar with the issue which motivated me to write this. I'm sadly quite sure that it applies to your own industry too, whatever that might be. The thing is, there's a disease in the software development world, a sort of sickness.

Sickness. It's an unusual sickness in that it's often not something you acquire once you actually join the industry, like graying hair, caffeine addiction, and an ulcer, but rather it's something that new recruits already have when they arrive. Now a quick clarification before I continue. When I say new recruits, I don't just mean graduates and other young people. There are those who will say that this sickness is a product of modern Western education systems, and that things were perhaps better back in the day.

Maybe that's true, and maybe it's not. But I'm not qualified to say, and That isn't the position I'm putting forward here anyway. The illness I'm talking about seems to apply to both young and old alike. The illness, of course, is a flawed approach to solving problems. Here's an example, which is an actual quote from a web forum.

Number 1. Can we establish HTTP connection in application? If so, I need that code. I checked NSURL connection. I cannot integrate that code.

Number 2. I want to display a image from the website. Can anybody please provide me the code? If anybody having sample program, please give me. So what's the problem?

It's not the quality of English. It's reasonably evident that English may not be this person's first language. And that doesn't matter as long as the intent is clear, which it is. It's not the punctuation and grammar, because those things, again, aren't particularly important in this context as long as they don't become barriers to understanding what's being asked. The problem is that this person's problem solving technique is to ask for the solution, not to seek advice on how to approach the task, or ask for the names of likely classes to look into, or a link to an example, but to just ask for the code fully formed and ready to go.

This is not problem solving, and software engineering is entirely about problem solving. The interesting thing to note here is that the above example isn't actually as bad as it could be. There's one tiny glimmer of light to be found in the assertion that this person, quote, checked n s URL connection. That inspires some small amount of confidence since NSURL connection is indeed a suitable class to learn about when wanting to make an HTTP connection in Cocoa. However, it seems that, quote, checking, it was pretty much the sum of our friends' effort.

They, quote, cannot integrate to that code and have thus given up. This is an issue we all see constantly, and I don't mean having trouble making HTTP connections. There's an entire class of so called developers whose first and final tactic, when given a problem to solve, is to simply ask for the completed solution elsewhere, commonly on web forums or other suitable help channels. Their goal is the same as ours, to have code which solves the problem, which can then presumably be delivered to the client. The goal is reasonable and quite normal.

What isn't normal is the unwillingness I hesitate to say inability because, after all, very few things are truly fundamentally hard if you apply sufficient thought and effort. What isn't normal is the unwillingness to achieve that goal by a process of self education, honest attempts, and the classic iterative process of refinement and improvement until something acceptable is created. This process in turn equips you better to handle the next challenge, and sooner or later you find that there are entire sets of familiar problems to which you already know the answer and can approach with confidence. And you're quite capable of approaching unfamiliar problems by generalizing your current knowledge and conducting some simple focused research. This isn't some trick of software engineering.

This is the entire process of learning how to do anything at all. It's not a secret handed out at institutions of higher education. It's just how things work. You begin with a lack of understanding about a topic and need to solve a problem in that topic area. The honest, sustainable means of doing so is to improve your understanding.

This is achieved by, 1, formulating a question which when correctly answered, will improve your understanding in some way. Then 2, attempting to answer it. Note the second step. To argue that grabbing the completed solution in some way satisfies this process is laziness and intellectual dishonesty, and probably renders you unworthy of being helped. For after all, why should someone else do your work for you?

I've had a lot of personal experience with people displaying this troubling unwillingness to learn or research or try. I've released a lot of code over the years, and I'm very visible in the open source community for the platforms I work with. Since open source contributors seem to be seen as freelance teachers, that means I get a lot of email asking for help with one thing or another, and I provide that help whenever I can. I've helped literally hundreds of people looking to get started with Cocoa since Mac OS X was first released. I don't send boilerplate replies either.

I replied to each email individually, everything from specific code issues, including, but by no means limited to queries relating to my own code, book recommendations, right up to advice on how to get started with programming as a whole. I've done my duty in that regard, and I really do believe it is a duty. People who can do something to whatever extent ought to help others who wish to be able to do the same. Surely that's a fundamental truth and indeed a desire for all of us. But this is real life, and no principle comes without the consideration of certain realities.

Help may be free for the most part, but that doesn't mean there isn't a cost benefit ratio to be considered. My benefit may come from a warm fuzzy feeling rather than cold hard cash. But if you're wasting my time, then you're not going to seem as worthy as someone who genuinely wants to learn. Here's a secret. Willingness and desire to learn are the true qualifications, not ability.

We all have different innate and developed levels of ability to acquire certain skills. Some, probably most, of these can be improved with practice and some can't. And, it's wrong to pigeonhole or generalize a person's ability in an entire discipline just because of their seeming difficulty in one particular aspect of that discipline. But if you want someone to spend time and effort, especially if it's time they're giving freely, then you'd better earn it. Earning it isn't about throwing a few units of currency at your teacher, and it's not even about successfully completing your task.

It's about bloody trying. And trying is what so many of the type of developers I'm talking about seem bizarrely unwilling to do. So, of course, many of us ignore them. Problem solved. Right?

Wrong. There's a huge knock on negative effect of the proliferation of this unwillingness to make the effort to solve problems yourself. People who are in a position to help stop frequenting the chat rooms, forums, and mailing lists. Bad signal to noise ratio, they say, with some justification. The losers are the genuine, by which I mean well meaning, willing to learn people, who just happen to be new to a particular area, developers who naturally choose those places to ask their legitimate questions.

These people have a reduced chance to get meaningful guidance because of the effort involved in working out who's a lazy time waster and who isn't. This is an awful thing and it's never been more relevant since, logically, platforms which are young and or experiencing a surge in popularity are exposed to this phenomenon the most. There are fewer people who are genuinely experienced. The average level of experience is less, and the amount of help being requested is higher. There's a far higher proportion of lazy, grab the money and run types mixed up in it all.

This is the iPhone, Android, and so on. So if you're going to ask a technical question, I guess the first thing I have to say to you is, great. You're asking a question. And that means we have a better than even chance that you want to learn something. That's usually awesome, and I stand ready to salute you.

But wait. Have you considered, really considered, what it is you're about to ask? Is this the right time to ask, or can you take one more step first? Which might either make your question clearer or even unnecessary Try taking a few minutes to run through these points. Have you broken the question or problem down sufficiently to really ask something concrete?

In software engineering, you can pretty much divide problems into the 2 categories of, 1, things that can be broken down further, and, 2, things you already know how to do or can look up trivially. Is your problem the sort of standard question for which there's definitely already some sample code and documentation available? Skim the documentation or do a quick search. If your problem is that simple, the answer is probably just moments away. You can find it.

Try searching the web. This is glib advice, I know, but stay with me. If you're having trouble getting a decent result, you need to narrow things down. Don't search for if statement if you're just interested in an if statement in Ruby. Instead, try Ruby if statement.

Someone else has probably asked your question or maybe a 100 someones. Okay. So you've gone through those steps and tried at least a few of them. Them. I can now finally say congratulations.

Either you've solved your own problem, great, or you are now officially ready to be helped. When I ask, what have you tried? You can say with confidence that you've tried all that stuff above, and you can tell me anything promising you found, or you can say that you've at least come up empty honestly. I'm going to help you at this point because I can see that you want to learn and that you're willing to work for it, and so I want to teach you. That's the key realization.

When you're asked, what have you tried?', it doesn't mean, show me the code you've written or piss off. What you have to do is at least try to help yourself, and the trying is the important thing. Not just for avoiding pissing off someone who would otherwise be willing to give freely of their valuable time to help you, but actually for your own development. Do it enough times, and the number of questions you'll actually have to ask will start to go down. You'll also be in the position to help others, including me.

And that way everybody wins. So the next time you're considering asking a question, you'd better be ready with a convincing answer when you're asked, what have you tried? If your answer amounts to not a lot, take my word for it. The next question you get back will be, then why should I help you? Let's take a look at some of the highlights from this article.

At the very beginning, the author talks about a scenario where a guy comes to a forum, says, I want to display an image from the website. If anybody has a sample program, can you give it to me? And then the author says, this is not problem solving, and software engineering is entirely about problem solving. And the reason I like this concept so much is because it doesn't just apply to software engineering. In fact, it doesn't just apply to your job.

It can go as far as to apply to your entire life, asking yourself the question, what have I tried? Unfortunately, there's a huge temptation with this question to be dismissive of other people. The guy who wrote this post wrote another post 7 years later called Hindsight, where he was looking back on the what have you tried post. And his conclusion was that he wished he'd never published it. And that may sound odd, because this is such a good idea, such a good question to ask, what have you tried?

But unfortunately a lot of people took his post and used it as a way to be dismissive of other people asking questions. Instead of trying to help at all, they would just say, what have you tried, throw up a link to his article, and not really help any further. It got so bad, in fact, that the largest question and answer programming site, Stack Overflow, had a link back to this article in 2.2% of all questions. It got so bad that they banned links to this article because people would just come in and say, what have you tried? What have you tried?

There would be like 10 comments that just say, what have you tried? Let's not use this as a way to be a dismissive jerk to your friends and coworkers. Instead of applying this externally and being dismissive of other people and saying, what have you tried? Get out of my office. Let's apply it internally and look at ourselves when we come up against a problem and ask what have I tried?

Because what we're trying to do is gain understanding. Let's look back at the article. He says, it's not a secret handed out at institutions of higher education. It's just how things work. You begin with a lack of understanding about a topic, and you need to solve a problem in that area.

The honest, sustainable means of doing so is to improve your understanding. This is achieved by 1, formulating a question, which when correctly answered will improve your understanding in some way. Then 2, attempting to answer it. And step number 2 is really the whole thing. Right?

If you formulate a question, and then go and someone gives you the answer, then you haven't done the work, you haven't attempted to solve it, and you haven't really learned anything. You need to know how to solve the problem. You don't need the answer, you need to know how to get to the answer. Because that'll make you better at solving the problem next time, and solving the next unforeseen problem. Because that's what most jobs are, that's what life is, It's just problem solving.

So the better you can get at solving problems on your own, the better you'll be at your job, the better you'll be at pretty much everything. And that starts by asking a good question, and then trying trying to solve it. And along the way, you're going to find things, as you attempt to solve it, you're going to find things that don't work, but you're also going to find some things that do work. And once you find something that does work, that gets you one step further, and then you can ask a different question. Then, when you reach the end, and you really can't go any further, and you have no more questions to ask, then you can go to somebody and say, hey, I started with this question, and I'm about halfway down the road and I've figured out a good part of it, but now I'm kind of at a dead end.

Here's what I've done and here are the last few things I tried that didn't work at all. What do you think? Can you help me? God, how much better is that than when someone comes to you and says, hey, I just ran into this problem 2 seconds ago. What's the answer?

There's nothing more frustrating in the world than when someone has a problem and they immediately get up and walk over and go, hey, I just had this problem. Can you fix it? That's not helpful. But when somebody comes over and says, hey, I ran into this problem and I did all of these things and kind of got there, but now I'm stuck. Can you help me?

Then you think, oh, man, you got a long way. Let me see let me see what else we can do here. So you're 1, more likely to get help. And 2, you got halfway there. And so next time, you're starting out that much further ahead.

Next time you run into a problem, before you go ask your coworker, go ask your boss, post it on the forum and wait for someone to answer it for you, ask yourself, what have I tried? And is there anything else I can try? What's the next thing I could try? Is there anything that could get me a little bit further down the path towards the solution? It may not get me the solution, and that's fine.

But what what moves me one step forward? There are so many people who don't want to try. They don't want to figure things out for themselves. They just want to be able to a question and have someone hand them the solution. But that doesn't have to be you.

You can push yourself one step further and say, what else? What else could I try? What would get me a little bit closer? What might work? And when you do that, you learn.

Next time you'll be better. Next time you'll ask a better question. It's not that difficult. You just have to try. Today, ask yourself, what have I tried?

You can see the show notes for this episode or leave a comment by going to musicmakers.fm/2. You can subscribe in Itunes by searching for Musicmakers. And please leave a review by going to musicmakers.fm/review.