I'm here with Jeff LaMarche. [treehouse friends]

He is a prominent developer in the iPhone development community.

He's written quite a few books, and he is the founder of MartianCraft.

One of. >>One of. Right.

Why don't you tell us a little bit about how you became an iPhone developer.

I've been programming for a long time. [Jeff LaMarche - Programmer and Author]

I didn't actually start doing it professionally until the dot com boom.

There was such a shortage of talent that they were willing to look at people

who didn't have traditional backgrounds.

I sort of got my foot in the door working at a company called PeopleSoft.

What were you doing? >>I did a number of things.

I actually went to law school. >>So you were a lawyer.

For about 20 days. >>Oh, okay. [laughs]

I passed the bar, and less than a month later I was out the door.

And then I did whatever I needed to make money.

I did clerical temping. I did pretty much anything.

I did some graphic design work even though I didn't really have a background with it.

I just kind of bounced around and did whatever I could to make money.

So what made you get into software development?

I had been programming as a hobby since 1980 just for fun.

I was going to go to school for it.

Sort of a long story. I didn't end up going to school for it.

This place where I went to school wouldn't let me test out

of some of the earlier level classes, and it was just really boring for me,

so I decided to do something else.

And then it got to a point where I didn't have the right background.

And then the whole dot com thing, there was such a shortage

it gave me the chance to get back into it.

So basically, the dot com boom you got into software development.

Doing it professionally. >>Full time. >>Right.

I did that for a few years and then I went out and was doing consulting,

travel-based consulting, which was interesting technical problems

but a horrible work environment--awful.

Large bureaucracies, big companies, and just traveling all the time,

48, 50 weeks a year.

So what were you consulting on? Java or--?

A lot of what I did was PeopleSoft.

I didn't start this way, but I sort of ended up with a specialty

in doing very large volume data integrations between systems,

which is not what I would have chosen, but it paid well and it was steady work.

So you were actually coding. >>Oh yeah.

I was always a technical consultant when I was out there.

I worked in the management consulting realm,

but I was always the technical guy.

And so I did that, and I was rolling off of about a 2-year, 2½-year project

in March of 2008 when they announced the iPhone SDK.

I had been coding for a long time, I had been doing Cocoa on a hobby level

since whenever they came out with OS X DP3, so--I don't know--'98, '99.

I had written for MacTech magazine. I did their Cocoa article for a while.

And before the press event was over, I called Dave Mark,

who had been my editor-in-chief back at MacTech,

and I said, "I think this is going to be big. I want to write something."

At that point he was actually in the process of selling--

he had a small publishing company--his catalog of books to Apress.

They wanted a book on the iPhone, so within a week or 2

we had the contract to write the book.

So had you written an app yet or you just wanted to write the book

because you knew the language?

I actually had made this call before we could download it. >>Oh, wow. Okay.

So I made the call and then I went and downloaded the SDK. >>[laughs]

But I knew it was going to be based on a technology that I had worked with

and had even written about.

I actually had written about 90% of the Cocoa book for Dave's company

that had never gotten published.

Actually, part of it did get recycled into the Apress Learn Cocoa book

but very heavily recycled and rewritten by Jack.

I actually was in the process of writing a very similar book,

was able to recycle some of the conceptual stuff,

and yeah, it was lucky timing and an opportunity for me to get off the road

and to get into something that I wanted to be doing more

rather than doing something that paid well.

I took quite a cut in income-- >>I can imagine.

for a while and it's starting to recover now

because obviously this is a great place to be right now. >>Oh, absolutely.

You went from something tried and tested to--

You took a risk because back then

nobody knew what was going to happen with the iPhone. >>It was a risk.

It was a pretty big risk, mostly because I had to take several months of no pay

to write the book.

But I always knew I could go back to that if I wanted to.

There was always work there, so it wasn't a huge risk but it was a financial hit for sure.

It was one of the best decisions I ever made.

So the iPhone comes out and what's your first reaction?

When they announced it, I was kind of like, "Yay, a phone."

I'll be honest with you. I honestly didn't see the hype at first.

And then when I actually held one I was like, "Oh, this is nice."

I was very much a minimalist phone person before that.

I wanted one that was solid because I traveled a lot

and I tended to be rough on phones.

So I wanted something that could sort of put up with abuse and make phone calls.

That's all I really wanted. >>Oh, wow.

So you didn't have one of the BlackBerrys or something.

I had no interest in those.

The iPhone was just a completely different beast,

and once I held one and played with it, then yeah, I had to have one.

So did you automatically start having all kinds of visions of different apps

you can build for this thing, or was it not that big right away?

Not right away because it took me about 4, 4½ months to get the book written.

When I started writing it, everything was in Flux.

The first version's Interface Builder wasn't there.

And then Interface Builder was there but parts of it didn't work.

Some parts worked and then in the next version Interface Builder would work

but they would have changed stuff, so your old NIM files wouldn't.

It was this constant--

A lot of the early chapters were completely rewritten several times. >>I can imagine.

And so it was a very long process.

I wasn't really thinking of apps larger than the scale needed to show concepts--

what I needed to teach somebody.

It wasn't until I finished the book, sort of had it in the can, that I sort of moved on

and started thinking about apps.

But I needed money, so I didn't want to go into selling an app in the App Store

at that point because I needed faster money.

So I went into doing some contracting. >>Sure.

Writing a book makes you the authority.

I read your book. That's how I got started.

This was actually before the book could be published

because I don't know if you remember we had the NDA. >>Oh, right.

So we actually sat on this manuscript for quite a while.

It was basically finished in August-ish.

I think we revised one of the later chapters maybe in September,

but it was basically done and ready to go.

At one point we were actually hearing from inside Apple

that it probably was not going to drop at all; it was just going to be there forever.

And then the next day it drops.

And so all of a sudden it's back on.

I had to go back to working during that time.

I wasn't an authority at that point.

But there were no authorities-- >>Exactly.

It's so new that anybody could be the authority. >>Right.

Although you had the advantage of having experience with Cocoa for all those years.

Right, which was helpful because obviously there was a much higher demand.

The old joke in the Cocoa community back in the early 2000s was,

Do you know what the difference between a large pizza and a Cocoa developer is?

A large pizza can still feed a family of 4. >>[laughs] >>That was the joke.

There were jobs, but there weren't a lot and there wasn't a lot of demand.

It was a very specialized skill. >>That's why you did it as a hobby.

Yeah. And a lot of people did because it was hard to make that jump.

So did you write apps for the Mac? >>Small ones.

Some framework, some small utilities.

Nothing ever got very high profile.

How I met Dave was he was actually Googling around

looking for someone to write a Cocoa article for MacTech

and he found my page where I had all the source code that I gave out,

and he sent me an email.

It kind of went from there.

But yeah, I really didn't have anything of large scale at that time

because it was fun, so I didn't want the hassle at that time of selling, of marketing.

I wrote it and once it was done, once I had learned what I wanted from it,

I was done with it and I put it out on the Internet for other people.

That's benefited a lot of iPhone developers, especially your blog.

I know when I was starting out, your blog was almost like a Bible for me

[Jeff LaMarche's Blog - iphonedevelopment.blogspot.com]

because you have so much code there, you have so much knowledge

that I really appreciate that. >>Thank you. That was funny.

I actually grabbed that domain the same day they released the iPhone SDK.

But then there really wasn't anything I could publish at first.

So I had this domain.

I think I did a hello post where I said,

"Some day I'm going to be able to write about developing apps for the iPhone."

A lot of the blog posts, especially the OpenGL ones,

came out of--I spent 4½ months really heads down on the most basic stuff,

and I really wanted to sort of get in and do some more stuff

but not with this incredible obligation of doing a 600-page book.

It's kind of an ordeal.

You get to the end of it and you really don't even want to read

what you've written anymore.

So that was an outlet--that I could write and I could explore

and I could learn things that I wanted to learn and have a reason to do it.

Since you've written a book for beginners,

for someone that's never programmed an iPhone app or never programmed at all,

what is the stating point for that person?

They have this idea.

I'm sure a lot of people come up to you and say, "Hey Jeff, I have an idea for this app."

And you're like, "No, no, no. Why don't you just build it yourself?"

But where do they start?

That's a tough question because I think a lot of people come into it

especially back when we were seeing all those mainstream news stories

on the App Store millionaires in the early days.

A lot of people wanted to do it and really didn't fully understand

how much was involved.

Where do you start? I think it really depends on people.

I've taught some workshops and I've written the books

and I've had interactions with a fair number of people who have written to me,

and one thing I've learned is that we're very different.

Everybody learns differently.

A lot of this stuff different people learn it in different ways better.

When you're sitting in a workshop and actually working with people

and seeing how you can just use words and this person gets it

and this person over here, they really need you to sort of draw a picture

or they need you to draw a parallel to something they're familiar with.

So it's hard to say. I think that you have to start with really the desire.

It's not the desire to make money because there's lots of ways of doing that.

It's the desire to create, it's the desire to do something.

It's not just, "I've got an idea," it's, "I really want to do this."

"I want to create this thing."

If you don't have that, you're going to get halfway through the book and be like,

"I'm going to do something else."

So I think you have to start with the desire basically.

But where you go from there really depends.

So desire to create an app or just desire to be an iPhone developer?

I think a lot of times it actually is much more basic than that.

It's a specific idea: "I want to create this."

It's not that, "I want to be an app developer," it's "I've got this idea."

"I want to see it come to life."

I think there are people that are like, "I want to be a developer."

It's a larger aspiration. But I think a lot of people it starts with, "I've got this idea."

"I want it to become real. How do I get there?"

Where you go, obviously now there's lots of books,

there's video training, there's actual workshops

where you can go and be taught.

So there's lots of paths. I don't know that there's 1 that's best or right for everybody.

A lot of it depends on how you learn.

I think going to an actual class for a lot of people is going to be a lot faster of a path

because you make mistakes-- >>Because you're used to that.

Yeah. You're there, you get to make mistakes,

you've got someone who can help you when you make the mistakes.

You're not just spinning your wheels.

I can remember when I was first learning to code back in the '80s.

We didn't really have Google.

We didn't have the Web. >>Or YouTube. >>Or YouTube.

We had Usenet.

You could go out to the comp.sys.mac--

I don't even remember the news group anymore,

but there was a place you could go.

You'd ask your question and maybe a few hours

or a few days later you'd get an answer.

All the documentation were in these big, thick volumes that you had to buy.

So it was kind of a different world.

Something that's fairly simple and a more experienced developer could help you with

might be something you'd spend a week on back then

just because you didn't have access to people.

To resources that you have today.

I don't think there's ever been a better time for learning this stuff

because there are so many resources.

You're going to be able to find something that works for you if you really want to do it.

So you said that you have to have a desire,

and I truly believe that when you're starting out to learn any piece of technology

or framework or SDK or anything like that,

if you start out with an app--in my case the idea is an app,

a mobile app or a web app or something like that--

and then you're trying to learn the different aspects that will get you there--

So you have the goal in mind and then you're trying to piece the puzzle,

what will get you to that goal.

Do you think that's a fair way of getting to that goal? >>Absolutely.

There was no real opportunity--there was, I guess, some opportunity

but there wasn't as much opportunity for the training.

Aaron started the Big Nerd Ranch back in the late '90s or early 2000s,

and that was really the only place you could go to learn Cocoa.

It was probably out of reach for a lot of people because you had to travel there

and stay there for a week.

For most people it was.

You were using a book, you were using API documentation.

Now there's so much.

But when it comes down to it, it is like a puzzle.

You're going to learn this piece, and you can't really see what it's a picture of,

and then you get this piece, and at some point your brain sort of clicks and goes,

"Oh, I get it. I've got the big picture now."

It's a slow process, unfortunately.

Yeah, unfortunately, it's a very slow process

because there are so many different concepts.

Is it easier now or was it easier back then to pick up iOS?

Of course with ARK they've taken that whole equation

of memory management out of the way,

so it's easier to be an iPhone developer, I feel,

because the tools have evolved, there's Xcode that's evolved,

Interface Builder evolved.

The tools are evolving, so is the SDK.

In my day [both laugh], we walked 10 miles through the snow barefoot.

I think conceptually the manual memory management

was really a hangup for a lot of people.

It took me a long time to get it.

It's funny. Once you get it,, you look back and you say, "Why was that hard?"

It's basically 3 rules.

I can list them out, it's simple, and yet you sit there--

I can remember sitting there and being like, "Maybe I'll throw another release here."

"Maybe that will fix it."

It's sort of an easy concept but it's not easy for your brain.

It's simple but it's just not the way your brain works--most of us.

It's not the way your brain works naturally.

That was an obstacle for a lot of people.

I don't think that they've necessarily made it easier.

I think they've removed an obstacle.

I don't think that it's necessarily fair to say they've gotten rid of it

because I think you really do need to understand memory management

to do it properly because with ARK you're going to hit edge cases.

But you can get something running, you can get an app up and running

without knowing the memory management.

And so I think you've dropped an obstacle,

you've dropped something that would catch some people early on

and discourage them before they really got far enough along to really get excited.

I think it's better in a lot of ways.

I don't know that easier is the right word because there's just so many pieces

of the puzzle. It's a big puzzle.

They made 1 complex piece of that puzzle a little less complex,

but it's still a big puzzle and there's lots of pieces you have to learn.

I think it would be unfair to say it's easy or even necessarily easier,

but they've removed an obstacle, and I think that's good.

I think it encourages people to do it.

I'm a big Apple way of doing things kind of guy,

but one thing Microsoft really has always been good at

is lowering the bar for developers, making it easier.

I don't always agree with the way they did it,

with some of the choices they made in the process,

but that was always a focus for them is sort of lowering those barriers to entry

for developers.

I think that's something we almost had as a point of pride--

that there was this memory management and you had to get past it.

You had to get past your hump before you were part of the group.

It's your rite of passage. >>Yeah.

I think that was sort of almost--

When you say it out like that, it sounds a little silly,

but I think it almost was that kind of mentality for a while

and I think pure survival just because we've had such an influx.

We've had to start taking it more seriously and making it more approachable,

and I think that's what Apple has been doing and I think it's good.

But I don't think it's easy, and I think it's unfair to say it's all of a sudden,

"Well, now you don't have memory management. It's easy."

Well, no. It's easier.

Yeah. >>Like you said, they've removed 1 obstacle. >>Yeah.

You're freeing up capacity for more problems that you have to solve. >>Right.

I think that's one of the things that a lot of us like about software programming

and engineering in general is there's always more problems to solve.

Somebody gets rid of that one, makes it easier.

I don't have to write accessors and mutators now. Great.

That frees me up to do something else, to solve more complex problems.

It's why we continually get better and more complex software. It's great.

I started learning iPhone development.

So I'm on my way, I'm getting a little better.

How can I become a better iPhone developer?

I know the basics, I know the patterns, I understand my way around the tools.

How do I get better?

I think the simple and obvious answer is the more time you spend doing it,

the more feedback you get, the more mistakes you make.

Having the opportunity to work with other people is great.

While I was learning to code it was pretty much me,

and I would reach out to places when I needed help, but it was mostly me.

And I think when you have people,

especially if you can find yourself in a situation

where you have more experienced people you can draw upon,

you still have to solve the same problems,

but they've seen those problems before and they can help you get to the solution faster.

So I think working with-- >>Having a mentor?

Having a mentor or just working with other experienced people,

seeing how other people work, putting in a lot of time.

I think a lot of it just boils down to-- >>Practice?

Practice, but is your head in this? Is this really what you want to be doing?

Do you want to be here?

People think we're kind of crazy, but our hiring process is sort of weird.

A lot of times we don't even look at the education section.

So what do you look for? Right.

You own a consulting firm, MartianCraft. >>Yes, co-own MartianCraft.

A lot of it is we meet people, we kind of keep an eye on people

that we think down the road might be good when we've got an opening.

But a lot of it is we look for people who are part of the community,

who come to conferences, who participate in the dev forums

and mailing lists and they enjoy it.

I think the answer we try to get to the bottom of, and it's not always easy,

is if this person couldn't make their living doing it, would they still want to do it?

That's an interesting question. >>Yeah.

Or at least something similar.

Is this really what they want to be doing,

or is this they saw that it was profitable and they want to be part of that?

I think the real things-- >>Of course they're doing it

because they want to make a living off of it. >>Of course.

But is that your primary motivation, because there's lots of ways of making a living.

Have you soaked in all these stories of the overnight App Store millionaires' success

and that's your real motivation,

or are you enjoying the path, are you enjoying the ride? >>Right.

So with enjoying the path you mean just enjoying developing? >>Yeah.

Enjoying putting an idea out there and seeing it to fruition?

The day to day. Do you enjoy the coding? Do you enjoy the problem solving?

Do you enjoy the collaboration with designers?

Do you enjoy the whole process, because basically when you think about it,

there's nothing else, with the possible exception of sleep for some people,

that you're going to spend more time doing than your job, your career.

And if you're not happy--and I can tell you this from when I was doing all this traveling--

I liked the basic problems that I had to solve, but I hated everything else around it.

I was miserable.

You didn't like the traveling, the dealing with the clients and all of that.

The traveling, I didn't like dealing with the bureaucracy,

I didn't like all sorts of things about it,

and I basically took more than a 50% cut in pay and was thrilled.

I worked for free for 4 months, and I was happy about it.

I think trying to get to it, trying to figure out do they really want to be there,

do they enjoy solving these problems, and from there, a lot of these other things--

Did you go to Stanford? I don't care if you went to Stanford.

I've met some awesome developers from Stanford,

but I've met some awesome developers that never even finished college.

There's a lot of different paths to it,

and we don't get too hung up on what path they took to get where they are.

So you did freelancing for some time too, right? >>Mm-hmm.

What's your advice to some of the freelancers if they are going to become

freelance iPhone developers?

I think that's one of the biggest barriers for someone that's a developer--

to go out there and get more business because naturally,

most developers are not marketing people.

They can't go and sell themselves.

They'd rather just sit in a corner and write code, which they're really great at,

but they can't really go out there and win the business.

Yeah. And this is not an easy question.

I'd love to say that I had a great solution and that the reason--

I mean from your experience, I guess.

The problem is my experience is a little unusual,

and that is because the book was successful

and because it was one of the first ones out, I had people coming to me.

We decided to form the business because we had people coming to us

and we were referring work to other people.

And we were like, "Whoa, whoa. Why are we sending all this work away?"

"This is kind of silly."

We never really had the problem of finding work.

If you go to our website, there's almost nothing there.

We've never gotten around to doing it because we have to turn down work.

Part of it is we don't want to grow too fast.

We don't want to accept every job that comes down.

We want to make sure that we're taking jobs that we find interesting

and various things, but we've never really had this sort of traditional problem

of how do you find the work?

Before the book was published, honestly, the first contracting job I had

after that actually was somebody I knew from back in the enterprise consulting days.

He had moved over, he was working at Rosetta Stone software,

they were sort of looking at the iPhone as possibly porting parts of their software,

so they wanted someone to come in and advise them on that.

So it was just a connection. It was somebody I know.

Obviously going to things like this, the more you can meet people in the community,

because finding the actual clients is hard;

finding other people--

People come to names in the community,

they come to well-known people in the community and they say,

"Are you available? If not, do you know anybody who is?"

And if those people know you and they know that you're available

and they know that you're good, then they're going to possibly

send some of that work to you. >>Okay.

So basically going out there and meeting more people and networking.

Yeah. It comes down to--and I hate to use this word having been a teenager

in the '80s and all the movies like Wall Street and I hate it--networking.

I don't think you should come to these events because you want to network,

but the more people you know, the more you socialize,

the more you get involved in the community,

the more opportunities that are just going to show up at your doorstep.

So if I want to build a consumer-driven iPhone app--

and now there are more than half a million of them out there--

how do you even stand out anymore?

[laughs]

We're actually on sort of the other side of that

because actually we've got 2 software development projects in house.

We've started a products division, but we're still several months out

from having our first product in the store.

[laughs] I guess a glib answer to that would be I'll let you know when we figure it out.

[laughs] >>It's hard.

I think you have to start out with it's got to fill a need

or it's got to be fun or it's got to be something that people will want,

it's got to be well written, it's got to be stable.

There is a certain amount of luck to it.

If you look at the apps that have been successful,

why was Angry Birds this runaway success and all the other trajectory apps

that all go back to these--

There was a cannon app back in Applesoft BASIC that was exactly the same thing.

Oh, was it? >>Basically. It wasn't touch controlled but it was the same idea.

You're calculating the trajectory, you figure out the angle and the velocity,

and then did you hit the target?

So it's not exactly a new idea.

A new take on it and well implemented, but there are other well-implemented takes.

There is an element of fortune to it, unfortunately. There is an element of luck.

But there's also a lot of elements that are not luck that you can take into control.

Some of it is, by and large, us engineers don't like to market.

We don't like to advertise. We don't like to write press releases.

So part of it is either learn to like those things and get good at them

or find people who are, partner up with people who are.

Some of it is persistence.

When you look at some of the real runaway successes,

there's sort of an old saying that overnight success takes a long time.

I think Angry Birds was Rovio's 18th game or something.

Yeah. It took them 6 years to turn out a hit. >>Yeah.

Temple Run was Imangi's 5th, 6th, 7th game. >>Okay.

The stories where somebody's first game hits like that are very rare.

People keep trying.

You learn, you get better, you get feedback from your users,

and you keep trying until you hit on the formula.

And it's a lot of work.

So let's say as an indie iPhone developer I found the right designer to work with.

What are some of the things that you would recommend as using some of the tools

like Instruments and stuff like that to turn out a high quality app

so that your app doesn't crash the first day in the App Store and stuff like that?

The first thing is to use the tools that are available.

There's sort of a lot of debate about Xcode for itself,

but when you look at all of the tools, there's a lot of really great tools

that Apple has churned out in the last 5 years

that we didn't have back in the Mac days.

Instruments is great, the GL debugger, the GL tools,

the Static Analyzer.

A couple rules that we have in house

is we never check in code that doesn't compile clean and analyze clean.

You can have sort of intermediate builds on your own machine

that have warnings or whatever, but our rule is don't check it in if it doesn't compile clean.

So by checking it in, you mean come into your repository. >>Right.

A lot of times we've been really, really lucky.

We have really, really good developers on staff.

They're fast, they're competent, they just write great code,

and sometimes I'm kind of feeling kind of stupid when I'm there.

I'm like, "Yeah, I'll help you guys. Oh jeez, you've already done that. All right."

"Yeah, that's good."

The young guys kind of make you feel old and not quite as smart as you think you are.

One thing that I always face as a developer

is that you're in this problem and you're so minutely focused on this 1 area of code

or something like that and you keep hammering away for hours at a time,

and sometimes you just walk away from it and then come back to it.

Yeah. Sometimes it's the best thing you can do. >>Right?

And a lot of times I'm not smart enough to do it when I need to do it.

[laughs] So you face that too. >>Oh yeah, all the time.

Sometimes it's just human limitations are the best thing in the world

because you're not smart enough to walk away

and then you realize it's 3:00 and you're like, "I've got to go to bed."

And then you get up the next morning and you're like, "Oh!"

Right. "That was so obvious."

Yeah. Oh yeah. Everybody hits that.

It's one of the things.

A lot of times when you first start working in a group environment

people are kind of embarrassed to admit when one of those happens

and you're like, "Oh no, we all do that."

That's just part of it.

When you think about the APIs now, when I started programming,

the entire operating system was 16K or something. >>Oh wow.

Everything would fit.

You could memorize the entire instruction set if you were writing an assembly.

It just was a very finite number of instructions.

It was a different world than we live in now.

I don't think it's possible for at least the vast majority of mortals to know all of it,

just even on 1 platform. >>Oh yeah, absolutely.

That's why I think our job really is to just keep learning,

is to be willing and able to dive in and learn what you need to do

if you haven't done it before. >>That's what keeps this interesting. >>Right.

It's always challenging because with every new release comes out new features

and new SDKs and--

And then there's old ones that you've just never had a need for before. >>Right.

That happens.

And then you will over time develop ones that you don't like.

I refer pretty much anything that's audio-oriented or give it off to someone else

because the Core Audio Libraries--I had a couple projects with them

and just realized that we don't get along that well. [laughs]

And you hit areas like that.

I can do it if I have to, but if I have the option of letting someone else do it,

I'm more than happy to let someone else do the Core Audio work.

Any last tips and tricks that you would like to offer beginning iPhone developers?

Tips or tricks.

No. I think just keep it fun, especially when you're first starting.

Don't bang your head against it.

If you're getting frustrated, go do something else; come back to it later.

There's a rate at which your brain can sort of accept these concepts.

And you can force the stuff in faster, but it's not really going to make you get it faster.

So keep it fun, don't beat yourself up, and just enjoy the ride and you'll get there.

You'll get there--eventually. >>Yeah.

And not as long as probably will think at times. >>Right. All right.

It's been great, it's been enlightening, and thank you very much for doing this.

Yeah. It's very nice talking with you. >>Same here. >>Thank you.

[treehouse friends] [??]