By: engr. Kainmi paul n.

Contents

1.triCk your Brain with the 20min rule

2. Code for a PurPose. have a ProjeCt

3. there is no “PerfeCt language to learn”

4. understand what you’re writing

5. it’s ok to not know

6. Be a CoPyCat

7. Be aCCountaBle to someone. show your

work

8. keeP learning

9. Play foosBall

10. get a mentor - try Pair Programming

11. get into the haBit of Chunking

12. Break someone else's Code

 1
triCk your Brain with the 20min rule
Learning to code is a bit like going to the gym. Even if you max out and spend a whole weekend at the
gym, you will not see a visible difference in your body. The more regularly you learn to code, the more
likely it is that you’ll start seeing your ripped coding muscles. (The irony is not lost on me).

But the problem is — where do you find the time? Between running your business, meeting clients, and
handling life admin, when are you supposed to sit down and practice this “daily coding”?

While I was working as a young business person, I spent about 12 hours managing my company
operations, about 1 hour commuting between meetings, and approximately 2 hours on general life-
sustaining stuff, such as eating. So that left me with only 9 hours remaining in my day.

Theoretically, 2 hours could be allocated to coding practice and 7 hours on sleep. But there is nothing
more difficult than trying to convince your work-saturated brain to sit down and learn when you could
be watching champions league with a glass of good wine.

But then I found a trick.

As humans, we have a lot of inertia. This can be bad for us — I’m looking at you, “24” box set. However,
we can also turn it to our advantage. I found that once I got started coding and making things, I got so
absorbed into the project, that I no longer cared about TV, food, or sleep. There were quite a few
weekends when I coded until sunrise.

So how do we take advantage of this inertia? First, you must understand that task-switching is very
difficult. It requires a lot of motivation. If as soon as you get home, you slump on the sofa and switch on
the TV, you’ve already lost that evening. This is because the amount of motivation required to task-
switch and do something not driven by evolution like eating or sleeping is a Herculean task.

This is why the moment you enter the door and change to a new environment is the most crucial
moment. If at this moment, you tell yourself that you are just going to do 20 minutes of coding practice,
you will most likely succeed and use your own inertia to end up learning for an hour or more. No brain
will perceive a 20-minute task as a lot of effort and you end up tricking your brain to take advantage of
your evening.

The next step is to develop a habit. Research suggests that in order to develop a new habit, you have to
carry out the task daily for a month. I’ve used this next trick for loads of different things, from exercising
to coding, it invariably works like a charm. To preface this trick, I want you to imagine a wall with five
paintings hanging on it, four of which are perfectly aligned, perfectly horizontal, but one is crooked. Now
really imagine it — is there a part of you that wants to fix it?
Now let’s imagine a monthly calendar with boxes representing individual days. If you nurtured that new
habit on a particular day, then you make a line through that day. If you continued your streak the next
day then you extend that line and so on and so forth. There is something about not breaking a
continuous line that motivates most people to continue to develop a habit.

As strange as it sounds, there are many times when I would have given up, but felt compelled to
continue because of a long, continuous line. Try it out with a printable calendar over here.
 2
Code for a PurPose
When I first started learning how to code, there were countless times when I picked it up then gave up,
again and again. This is a common story amongst self-taught coders.

Looking back, after teaching so many students, I finally realized what’s going on. A lot of beginners start
learning to code by picking an arbitrary language and following along with a bunch of tutorials. Copying
code, line by line — sometimes writing code to work out prime numbers, other times to find all the even
numbers. But you know what? I can find prime numbers a lot faster by Googling for it, and picking out
even numbers is really not all that interesting.

Here’s the truth — if you are learning to code for the sake of learning to code, it’ll be pretty difficult for
you to get good at it. Skills that require a lot of time to hone, like programming, will eat into your pool of
internal motivation — that something from within that makes you forget to eat and sleep.

I can honestly say that coding on my own projects is one of the most enjoyable things I do. It combines
logical thinking with creativity, and at the end, you will have made something. In most cases, something
that the world has never seen. Something that could make your life easier or more enjoyable. Something
that could make loads of people's lives easier and more enjoyable.

This is what motivates most people: the creating part. The making part. So, I urge you to start learning to
code by following a tutorial that makes something — anything. Of course, it’s unlikely that at the
beginning you’ll be able to code up Clash of Clans or League of Legends. But you’ll be able to make
something interesting. It could be a dice game or a flash-card app. But as long as at the end of the
tutorial, you’ll have made something you can use and play with, you’ll be far more motivated to code to
the end.

During all our courses, we always tell our students to think up a simple site that they want to make —
something that uses the skills they’ve learnt during the course but will also stretch them a little because
they have to find out how to include some new functionality.

We had a student who went on to make an application that wakes them up a minute earlier every day to
ease the transition to an earlier waking time. Another student made a custom slideshow app as a
Mother’s Day present.

There are no limits on your imagination. It will be difficult when you start working on your own
application because there are no step-by-step instructions, but it will also bring about the biggest
improvement in your coding ability.
 3
there is no “PerfeCt language to learn”
Whenever I do large talks, there will always be one person who asks me:
“Which programming language should I start learning first?”

There is this common perception that somewhere out there lies a perfect language for beginner
programmers. Some argue it’s Python, some say it’s Swift.

But I say they’re all wrong.

A programming language is simply a tool. It is no different from any other tool in your hardware box. If
you want to hammer a nail, you should be using a hammer. If you want to fix your water pipes, you’ll
probably need a spanner.

Yes, it’s possible to hammer in a nail using the side of a spanner — and the same programming language
can be used to solve different types of problems. The carpenter will tell you that his favorite tool is a
hammer and the plumber will say it’s the spanner, but it still doesn’t make it the “best tool to fix things”.

A web developer will tell you that JavaScript is the best language to learn for a beginner. A statistician
will advise you that you’ll be best served with the R programming language. But at the end of the day, all
that matters is what you are trying to do with your tool.

If you want to make iOS apps, then learn Swift. If you want to make websites, you’ll need JavaScript. But
the good news is the core programming concepts — loops, conditionals, functions, etc. — they’re all the
same.

The difference is mostly syntactical (rules of the programming language). In English, we have
werewolves. In German, they have Werwölfe. It’s still the same shirt-ripping mammal that comes out
during a full moon — it’s just spelled differently.

Printing to the console in Swift:

print("Hello Werewolves")

Printing to the console in Java:

println("Hello Werwölfe")

So, decide on the task that you are trying to accomplish, then pick the best tool for that task.
 4
understand what you’re writing
I have an issue with the way that most programming tutorials are written. There are far too many
tutorials where you see the “this is how you draw an owl” phenomenon.

It’s almost as if the programmer had good intentions and started off by showing you how to do
everything, step-by-step. But then, at some point, they realize that they have embarked on a Sisyphean
task and give up.

I’ve seen tutorials where the author starts off with an excruciating level of detail, then mid-way reverts
to “now you simply set up a cloud database” — bearing in mind that this is a tutorial aimed at beginners!
This leads to a number of problems. The most common problem is a student who just copies the code in
the tutorial and has no clue what any of it does. Why did they add that extra line after parsing the JSON?
Why is this dictionary being made differently from the last one?

It’s very easy to get knees-deep in one of these types of tutorials because it promises to teach you how to
build “Flappy Bird” or “Candy Crush”. But two-thirds of the way in, none of the things you’re typing
make sense and you start seeing red all over the screen — bugs. Loads of them. Why? No idea. Nothing
runs. The last 3 hours were spent copying code and you learnt nothing other than maybe that coding
sucks.

Don’t get into this trap. If you see a tutorial that jumps from beginner to advanced after line 3, or uses
the word “simply” too liberally, or doesn’t explain any of their code — stop. Leave that tutorial.

There’s plenty of fish in the sea.

Other times, the author does try to explain what they’re doing, but you still don’t understand a thing that
they’re saying. Then you’re in an advanced tutorial that won’t improve your programming. It can be
tempting to build grand things, especially when the blog is promising that anyone can make it. But if you
can’t work out what’s going on, you’d be better served by building a stronger foundation first.
The key to learning to code is all about ramping. You want to be stretched over and over again, and for
knowledge to be built on previous knowledge. If that ramp is too steep, you’ll get lost. If that ramp is too
shallow, you’ll get bored.

The right gradient is different for everyone. That’s why we encourage students to use the speed change
functionality liberally on our tutorials. This way, you can listen at double speed if you’re comfortable
with the concepts, and slow down to half speed if it’s something unfamiliar and you need more time to
understand and absorb.
 5
it’s ok to not know
Software engineers are purportedly the profession with the largest population of Imposter Syndrome
sufferers. Imposter Syndrome is a psychological phenomenon where people feel like frauds and
massively underestimate their own skills and abilities.

Programmers tend to be self-critical and constantly feel that everyone else is better at programming
than they are. If you’ve ever felt this way, you’re not alone — studies show that a massive 70% of
people have imposter syndrome.

I recently saw a post on the Q&A site Quora where somebody asked:
“Would I get fired at Google (or another big tech firm) if I got caught using StackOverflow as a reference?”

He got a bunch of really great answers from engineers working at Google, Amazon, and other major tech
companies. Anybody who has worked as a software engineer will tell you that not looking at references
is far more frowned upon. In fact, I challenge you to find a single Google programmer who has not used
Stack Overflow or AI. (If you’re not familiar, StackOverflow is a collaborative Q&A site for programmers).

A lot of new programmers are afraid that by checking references and asking people for help, they will
out themselves as a fraud who doesn’t know how to program. Nobody can hold all the relevant
information in their head.For example, here is the name of an iOS method:

- (id)initWithBitmapDataPlanes:(unsigned char **)planes pixelsWide:(NSInteger)width

pixelsHigh:(NSInteger)height bitsPerSample:(NSInteger)bps
samplesPerPixel:(NSInteger)spp hasAlpha:(BOOL)alpha isPlanar:(BOOL)isPlanar

colorSpaceName:(NSString *)colorSpaceName

bitmapFormat:(NSBitmapFormat)bitmapFormatbytesPerRow:(NSInteger)rowBytes

bitsPerPixel:(NSInteger)pixelBits;

It’s almost 400 characters!

In iOS programming, there are over 800 classes and 9000 methods — and that number is still growing.
In web development, there’s a new framework every week. No one will expect you to be able to
remember the code. This is exactly why we are programmers: we can get the computer to do the boring
stuff for us.

For example, the code for recording sound is only a short search away — why would you need to
memorize it?

The skill that most employers look for when recruiting is the ability to think. Knowledge was valuable in
a world where information was hard to come by. In the 1800s, only the rich had access to good books
and good teachers. Now, everyone has all the information they had — and more — at the tap of a mouse.

Information is losing value; the ability to think is the stock to buy. So don’t be afraid to search, to ask on
StackOverflow, or to find resources to help you solve your issues. The best programmers do it.

The skill you need to hone is in asking good questions and understanding the answer. There is no point
copy-pasting code from a StackOverflow answer if you have no clue how it works. Because
StackOverflow works on a reputation system, it’s in their interest to be as clear as possible in their
answer in order to be marked as correct and collect upvotes.

In most cases, it doesn’t make sense to start searching StackOverflow whenever you get stuck. The first
option should always be trying to figure it out yourself. If your program doesn’t do what you expected it
to, think: Before I typed the last 3 lines of code, it was working fine — so what in those last 3 lines broke my
app?

If you really can’t figure it out, start with Google. Search for your query, or if you have a bug, paste the
error codes and the error message. Chances are that as a beginner, your programming woes will be very
common — and somebody might have even taken the time to write a clear and concise tutorial to help
you understand your bug.

As you grow more skilled in programming, the problems you’ll encounter will become more obscure.
But hopefully, if you follow the other 11 rules, you’ll also be a more capable programmer and figure it
out yourself — or at least know exactly where to get help.
The other reason you should start with Google is that StackOverflow’s search algorithm organizes
questions and answers by recency, not popularity. A lot of the problems you will encounter while
starting out will have been asked and answered years ago — but are still massively popular.

So, ask wisely, and you will reap the benefits from the community. One day, when you yourself become a
code master, you’ll be giving back to that same community and helping the next generation of
programmers.
 6
Be a CoPyCat
At the beginning of my coding journey, I thought the way to learn to code was to read a whole bunch of
books. I bought books on C++, C#, Java and loads more. You name it, I had it. But they didn’t do much
other than make me confused.

I read. I highlighted. I forgot. I fell asleep.

Books are good as references — if you want to dive deep into delegates and protocols, read the chapter
on that. But if you want to learn, make something.

But what do you make?

Lacking in ideas? Be a copycat.

Make your own notepad. Make your own MS Paint. Make your own piano. If you’re into games, make
Minesweeper, make Tetris, make Flappy Bird. Not only will they be sort-of useful, but they’ll also be the
perfect opportunity for you to figure out how to do things and get experience in finding help.

Something that is brand new to the world — like holographic smartphone projections — no one will be
able to help you with. By making copycat apps or programs, you’ll be treading the path that many have
walked before you. This way, you maximize the chances that someone will be able to offer you help and
advice when you get stuck.
 7
Be aCCountaBle
Be accountable to someone. Show your work.

The biggest problem with online coding courses is the lack of accountability. No doubt there are loads of
great Massive Open Online Courses (MOOCs), such as Coursera, Udacity, Udemy, and Skillshare. But
what are the consequences of not doing your homework or missing a month’s worth of lectures?
Nothing. Nobody cares.

Let’s face it, internal motivation is not strong in any of us. We can always find a reason why we deserve
to “Netflix and chill”. I can’t even count how many online courses I’ve signed up to and subsequently not
listened to a single lecture or completed a single piece of coursework.

You need accountability and commitment to learning. Think back to your university days — would you
have bothered to finish that essay at 3 AM if nothing depended on it? Would you have gone to any of the
lectures if you didn’t care about passing or failing?

This is why we try to introduce accountability into our courses. We’ve realized that matching up
students with a buddy helps — someone else who is a beginner, at the same level as you, who
sometimes helps you and other times needs your help.

Sometimes, as people’s learning rates diverge or if you’re paired up with a lazy partner, you can swap it
up and get a new buddy. Because this system is entirely voluntary, there’s a degree of self-selection for
people who work well in teams and are motivated by others.

Just as you’re more likely to go to the gym if you sign up with a friend, you’re more likely to learn if you
have a coding buddy.

So, if you’re not on our course, then find your own. There are plenty of Facebook groups dedicated to
those who are learning to code. There’s even an entire subreddit (r/learnprogramming) dedicated to
this. I’m sure you’ll find like-minded people somewhere online or offline.

The next thing I’m going to tell you will be controversial. We believe that people don’t value things that
don’t have a value. This is the reason why Coursera is taking down a large number of their free courses.
They saw that millions of people were signing up for them but no one was actually taking the classes, let
alone completing the projects.

It was actually detrimental to students’ learning to offer a free course. We all have a degree of hoarding
tendencies and it’s very easy to sign up for a bunch of stuff that the future-you can suffer through.
“There’s always tomorrow,” she says.
So, if you are driven more by external motivation than internal, try to use a little bit of financial
motivation to drive your learning. Think about how much a life skill is worth to you and put your money
where your intentions are. See if you’re engaging with the course content more with or without the
financial commitment. There are plenty of places where you can pay something affordable to motivate
yourself to start a regular learning habit.

The final part of this rule is to try and find ways of getting assessed. Okay, so getting assessed is right up
there with death and taxes in terms of how much people enjoy it. But when learning anything, it’s always
important to get feedback. You will get an objective assessment of your current skill level, instead of
feeling like an imposter or brimming with false confidence.

Coursera has a system where the students mark each other’s work. At the App Brewery, we use GitHub
Education to test your code and look for bugs and problems. But if you’re on a coding course that doesn't
have a system like this, then it’s worth your while to find a code mentor who can review your code and
give you feedback. Only what’s measured can be improved.
 8

keeP learning
Being a good programmer is a bit like being Madonna.

Don’t run out and buy your cone-shaped bras just yet. What I mean is — programming will keep
evolving. In order to stay relevant, you have to keep reinventing yourself.

There are always new trends, new technologies, and new languages. Great programmers relish learning
new things, even if it means becoming a beginner again.

The world will keep moving — if you stay in one place, you’ll eventually be left behind. I know
programmers who never learnt anything else apart from Fortran. I know Objective-C programmers who
can’t persuade themselves to make the leap and learn Swift, even though Apple is telling developers that
Objective-C will be phased out.

We all know that Apple never makes threats that they don’t carry out — just look at the optical drive
(and soon the headphone jack?).

Don’t be the optical drive. Or rather, don’t be the laptop that’s still trying to play CDs. If your needs
change, learn to use a new tool. Keep learning. Stay relevant.

Are you a web developer who’s always wanted to get into mobile development? Pick a platform and
learn iOS or Android. Are you a front-end developer tempted by the full-stack? Pick up web development
with Node.

If you already understand the core programming concepts, picking up a few more languages will be a lot
easier than starting from scratch.

“Learn X in Y minutes” is a great resource for existing programmers to learn new programming
languages. Check out their resources here: learnxinyminutes.com
 9
Play foosBall
When you see Hollywood movies about programmers, they’re usually sat in front of a laptop, mashing
the keyboard like they’re in some sort of high-stakes “smash the mole” game.

When you see real programmers working, they tend to look like this:

Yep — that’s right. No typing. Just staring. A lot of staring.

In a company, people tend to complain that the programmers are always playing foosball or doing
something else that doesn’t look like work. People might not be able to tell, but they are in fact working.

When you see them enjoying their foosball game, laughing and joking, they’re probably suffering inside.
For there’s a bug. There’s always a bug. Or there’s something mysterious about their code that they can’t
work out.

Maybe the code is working perfectly, but unexpectedly (and programmers don’t like anything
unexpected, by the way). Like if they just typed out a thousand lines in one go — and unexpectedly there
are no errors.
Other people might not understand, but in these situations, it’s almost always worth stepping away from
your code and giving it some time and distance.

Do you have a bug in your code that you can’t work out? Sleep on it. Play foosball. Go for a walk. In 9 out
of 10 cases, the solution will become apparent. In the remaining 1 out of 10 cases… you’re just out of
luck.

This may sound unintuitive, but my advice is always to code less, think more. Once the poorly thought-
out code is written and brought into the world, you’ll inevitably have to go back and comb through it
line-by-line, refactoring and deleting things. This is always a painful experience.

So, remember — the easiest code to get rid of is the code that was never written.
 10
get a mentor
When I was learning French, I came across a method that resulted in the greatest leap in my speaking
abilities — having language exchanges over Skype.

I would pair up with a native French speaker who wanted to learn English. We would spend half an hour
speaking French and half an hour speaking English. We both dedicated an hour each week to improving
the language we were trying to learn.

While we were having a conversation in French, they would correct my pronunciation or grammar and
suggest ways to construct my sentences so they sounded more native.

Pair programming is an agile software development technique based on very similar principles. For
example, a learner and a mentor would sit down at the same workstation and work on a problem. The
learner writes code while the mentor reviews it line-by-line as it’s being written.

It can be uncomfortable at first because it’s a bit embarrassing making mistakes and having them
pointed out to you. But if you have a mentor who is a good teacher, they will offer you decades of
accumulated wisdom that can lead to massive improvements in your own ability — all within a few
hours.

You’ll get to tap into someone who’s had the time to hone their skills, find efficient ways of doing things,
and show you how they program and approach problems.

Good mentors don’t solve your problems for you — rather, they practice the Socratic method of asking
good questions that get you to think for yourself.

If you ask me how to write a networking call, of course, I can simply type it all out and get you to copy it.
But that doesn’t help you. Instead, if you show me how you approach the problem, and I show you how I
approach it, then you can learn so much more than just following a recipe.

The next time you encounter a different problem, you can apply the same approach and start solving it
yourself.

Always remember that information is cheap. A century ago, if I wanted to learn about the causes of
disease, I’d probably have to be an aristocrat, or work for years as someone’s apprentice. Nowadays, I
can search Google and get my answer in a few seconds.

So don’t get hung up on information. Learn to think instead. Learn how to approach a problem. How to
break it down. How to frame it. These skills will take you much further than simple memorization.

But where do you find a mentor?

There are programming-related meetups happening in almost every city in the world. Go to
www.meetup.com and find one related to the language you’re trying to learn. Attend the meetups, get
to know people. Exchange your expertise for theirs. Maybe someone needs accounting help. Maybe
someone needs legal advice.

Exchange your time for their time. Don’t say to someone, “Will you be my mentor?” — no one wants to
throw away their free time for a stranger. Instead, offer your help in return for theirs, and you’ll be
successful in finding a mentor 95% of the time.
 11
get into the haBit of Chunking
So, you have an awesome app idea. But it’s way, way, way too complicated for your current skill level.
What do you do? You join the Chunking Express.

Nope, I’m not talking about the art house movie. I’m talking about breaking down your programming
problem.

Let’s say you’re trying to make a robot that can butter toast. (If anyone is working on one of these, I’d
happily fund your Kickstarter!) The robot doesn’t know anything about toast, butter, or knives. Believe it
or not, it actually takes pretty sophisticated circuitry in our brains to achieve something as simple as
buttering a slice of toast. (This is probably why I can’t seem to do it without coffee).

So, creating a robot that does all of that autonomously is really complicated and difficult. But as good
programmers, we can do some chunking — breaking down the problem into smaller parts.

The robot doesn’t really need to know what toast and butter are — we’re not making Skynet here — so
let’s just stick to the practical things.

There are three things we need the robot to do:

1. Pick up and arrange the piece of toast in the ideal buttering position.

2. Pick up a serving of butter.

3. Place butter on toast with decent coverage (this is the part I find most difficult).

Next, you break each module down even further. In the process, you can think about alternate ways of
solving the problem. For example, does the robot need to “spread” the butter? Or can it just melt the
butter onto the toast? Does it need to learn to pick up a knife? Or can it have some sort of inbuilt knife-
arm, like a prison shiv pirate?

The more you break down problems and define the exact issue you’re trying to solve, the easier it is to
package your code into bite-sized chunks. The simpler the chunk, the easier it is to tackle.

So, the next time you’re trying to make that “cross between Snapchat and Evernote,” remember to break
down the problem into solvable chunks.
 12

Break someone else’s Code

One of the most important steps in making the jump from learner coder to a fully-fledged programmer is
understanding how to get help. Everyone needs help — even those so-called “God Level Programmers”.

But what you do with the help will determine how fast you progress as a coder.

On a site like StackOverflow, it can be very tempting to just copy and paste the code that someone has
provided. Your program works exactly as you hoped, and off you go on your merry programming way.

This exercise didn’t teach you anything other than code reliance. Because the next time you encounter
the same problem but in a different situation, that same code snippet might not work anymore. Then
what do you do? You’re stuck.

That’s why there’s a rule in programming that says: never copy-paste code that you don’t
understand.

So what should you do when you’re confronted with a block of code that solves your problem but you
have no clue how it works? Break it down.

Step 1 – Copy and paste the code into your program. (Yes, yes, I know I just said not to do that —
patience).
Step 2 – Make sure your program or application is functioning as expected. Confirm that the block of
code really did solve your problem.
Step 3 – Delete the copy-pasted block of code line by line.
Step 4 – Each time you delete a line, check to see what’s been broken. Does the app still run? What are
the error codes? What has deleting that line of code done to your program?
Step 5 – Even if you think you know what a line of code does, delete it anyway. The most important task
as a programmer is to test your assumptions against the outcome.

For the most enjoyable feeling as a programmer is for the real world to validate your assumptions. You
know how nice it is when someone you care about says those magical three words?

“You were right.”

It’s like that — but better.

Step 6 – Swap some of the lines around. Can the same functionality be achieved in a different order?
Why were they written in that particular sequence?
By breaking the solution code line-by-line, you’ll learn and understand what each line does and why it’s
been written. This is a far better way to use code from other people than just pasting it in and hoping for
the best.

Once you understand why each of those lines was necessary, the next time you encounter a similar
problem, you’ll be able to tease out the solution yourself.

When you’ve mastered breaking code from StackOverflow, the next resource to target is GitHub. It’s a
tool used by programmers for collaboration — but it’s also one of the largest repositories of open-source
code.

So how can you use it to become a better programmer? Let’s say you want to make an Instagram clone,
but you don’t know how. You head over to github.com and search “Instagram” or “photo app”.

Inevitably, there will be something written in Swift, Objective-C, or Java that you can download and
study.

Look at the structure of their program. Explore all the classes, constants, and interactions. Make some
modifications to the code — does it still work, or did you break it? Why? Was there a dependency you
didn’t notice?

Ask yourself questions. Learn through the Socratic method. Tear down the project and understand how
it was built.

When you start getting good at this, the next step is reverse engineering. Find a small project on
GitHub made by a reputable programmer. Download the app. Run it and explore its functionality. Play
around with it.

Then build it from scratch. Once you’re done, compare your code to theirs. Are there efficiency gains you
could have made? Did they solve something you couldn’t figure out?

Now you’re really getting into the big leagues.