Tutorials and Resources for Beginning Java Developers

Learn all the additional technologies you need to create a software project using Java. Use a database, create a web application or desktop app, and learn related project planning and code organization skills.

These resources were organized by Jenny Brown for CoderGirl St. Louis participants who are learning Java and working on a project, prior to interviewing for apprenticeships. You may also find them useful if you're a beginner learning to code in Java, and want to increase your skills.

Table of Contents

Project Management and Leadership

Requirements and Design Process

The design process is about deciding what app you're building, what goes in it, and how you're going to build it. A design document is a way to record your notes as you plan.

You don't have to plan everything ahead of time, just enough to get clear on what you're building and how. Write the minimal documentation necessary to clearly communicate your plan to potential teammates and keep yourself organized. Do write something; it will help your mentor give feedback and support your project. You can adjust what you include or leave out of the design doc, to best fit your project. A design doc is a handy way to explore an idea for a small, personal project, where you don't have customers to ask questions of, but still need to explore your ideas thoroughly.

Example Design Docs

I'm sharing some of my work-in-progress documents as examples. You can see how they clarify a problem and specify a solution. (I can't share job projects due to intellectual property ownership, so these are all free-time projects of my own.)

About Design Documents introduces writing a software design document.

Start here to plan your own design doc. It includes an outline so you have some idea what areas to think about and focus on.

Math Pairs Addition-Facts Game is a small project. You can also play the game online if you have Adobe Flash Player, or view the source code on github.

This was a learning project I did to get familiar with the basics of game design. It's a different code structure than business apps, so it stretched my skills to figure out how best to organize and simplify the code, while working effectively with Adobe Flash APIs. The design doc was completed after the project rather than before, so some areas (such as technical plan) are a bit thin. In any case, the design doc is still useful for an idea of how to design a fairly simple project. The code complexity of this is a bit less than what is desired for a LaunchCode project (in version 1, which is all that's done so far); it's a little too simplistic, but still useful for comparison.

Light Controller Web Application for Philips Hue lights is a medium size project.

This is a straightforward web application, with a bit of fancy user interface added in. The design doc is large because I chose to spend a lot of time analyzing usability, so I could plan better. The actual light control app is not that much work.

One experienced developer could complete this project, including testing, in 80-100 hours of work (3-4 weeks of a full-time job). 2-3 developers working together could complete a basic version of it in a hackathon, with 20-30 hours working together after the design doc was written. Then it would require some graphical polishing and testing to smooth out the user experience.

This is a little more ambitious than a LaunchCode-focused final project, but it's on a similar scale. If you completed an app of this complexity, you would have an easy time getting hired on as a full developer, not just an apprentice.

Software Code Base Analysis and Visualization, in contrast, is a huge project.

One experienced developer focused on this project in their full-time job would spend months or possibly a full year working on it. Accordingly, the design doc (once completed) will be much longer, as it explores more facets of the problem, digs into computer science and algorithm challenges, and makes plans for a larger, more robust system, including parallel computing. Notice that it focuses on higher-level planning, not fine details, and it uses prototypes to explore code ideas and plans iteratively.

Agile and Other Approaches

Other approaches to requirements gathering and documentation are common. You can find a ton of information by searching "gathering software requirements" online - and you can also find lots of challenges and disagreements on approaches. There's no one right way, and every company puts their own touch on how this is done. And, most any strategy will work out fine on smaller, personal projects; adapt the process to suit your needs.

If you are creating a large business application for customers, agile "user stories" are a way to examine the workflows needed in your app.

For example, a user story for Amazon's shopping site might be, "as a book reader using Amazon's site, I want to choose and one-click purchase a Kindle book, and immediately read it on my tablet." Lots of code features are needed to satisfy that (fairly complex) user story. The story gives a task goal, something the user wants to accomplish, but it doesn't specify how the software should work. The next step is the developers brainstorming how best to create that feature, both for user comfort and ease of use, and also so it fits in properly with any pre-existing software and workflows. If users can already buy books, and Amazon can already send books to tablets automatically, then perhaps this story is about the "one-click" aspect, in which case it might be a fairly easy, small effort. But if users can only buy physical books, not e-books, then this story might imply a massive coding project to bring e-books to the site. So even user stories benefit from some background knowledge and planning context; they're not a free ticket to skipping requirements decisions. They are a starting point, not an ending point.

The main thing you'll see agile process contrasted with is waterfall process. This is a strategy used in the 1980s and early 1990s for software, where everything about the product was specified in requirements documents (to a fine-grained level of detail) before the software was built. This approach was an attempt to make sure that (expensive, large) software products were building the right thing before they started, and possibly wasted a lot of time. But it didn't pay off; unlike mechanical engineering, the world of software has to change to fit human processes quite frequently. So by the time the software was finally built, the needs and goals had changed, and it was wasted time anyway. First, developers tried to improve on this by breaking it down into iterations, so they would plan one set of features, and build those, and then come back and plan another set of features, and build those. This helped - they were less far off target - and it seemed that the smaller and faster the iteration cycles were, the easier the process became.

Iterative waterfall eventually led to the discovery of the agile principles - namely, that working in small increments, being willing to change course, and communicating frequently and repeatedly with the customer, tended to produce value more quickly and lead to a better product. This is much like a writer working frequently with an editor, so that a story doesn't get too far off-course before it's corrected and improved. Since then, groups continue to experiment with varying approaches to agile development, seeking further refinements and to solve the sticking points that remain in various situations. You'll find a lot of contradictory advice online, as a result; and it's all true, from some point of view.

Project Management and Motivation

Managing Motivation and Energy

Staying persistent with a large project can be a challenge. The hard and confusing parts can be intimidating, resulting in procrastination and ineffective progress. How do you tackle something large? How do you stick with it until it's done? The key is to make lots of small tasks and incremental milestones, as well as separating out the ambiguous and confusing parts from the known and understood parts.

A design document lets you organize what you do know. It also lets you discover the questions you have, and areas where you might get lost if you tried to start coding immediately. It's ok to fill the design doc with questions as well as answers. Listing our your questions is a good way to discover what research you need to do.

A task breakdown is a listing of all the coding tasks you'll need to do. Some of these will be structural, like creating a skeleton of the app code, and making empty stubs for the primary classes and methods. Some of these will be detail-oriented, like filling in the code for a particular screen or feature. Some tasks have to come before others, since you can't write to a database before you've created one. The task breakdown is a big, detailed to-do list of the coding steps.

The task breakdown gives you a way to measure progress in small steps. Each task should take no more than 4 hours to accomplish (not counting learning time on something totally new). Some people also make tasks for the learning and research activities, so that those are covered in their plan as well. By listing out tasks to a 4-hour size, and putting them in order, you get a clearer understanding of the work to be done, and you can see the progress you're making against the list.

A daily scrum or weekly check-in is a common strategy used by professional teams, to stay on task and organized. At the daily meeting, each person reports what they worked on yesterday, any obstacles they are currently stuck on, and what they plan to work on today. It's a quick report without a lot of detail. The purpose is to coordinate activities, get people unstuck, and be able to adjust to changes in the plan as needed, as well as to keep the team energized. Daily meetings means they're checking in with their team once for each 4-8 hours of work they complete; your frequency may vary when coding isn't your full-time day job.

Notice that even professionals have a daily check-in about what is getting them stuck. Getting stuck during a project is normal! Pros help each other through the sticking points.

A feature demo can be a great way to keep your energy up as you work on larger projects. Each time you get a new feature added and working, show it to a friend or classmate, and talk about what it does and how it works. You can also talk about what you're learning on the technical side. Staying connected with other people helps you stay focused and determined to finish.

Taking a break is also important once in a while, to get a fresh brain and be able to see the context of your work. Go for a walk, get a meal and some sleep, or just go do something else for a while. Being fresh matters. You can also improve your concentration by reducing distractions, background noise, interruptions from other people, message dings and beeps, visual clutter, blinking lights, and anything else that will interrupt your thoughts.

Ambiguity is the biggest reason why people get stuck and procrastinate. "I don't know what to do." Being a software engineer means that it's your responsibility and duty to ask lots of questions to make the ambiguity go away. This means you'll be dealing with messy, confusing ambiguity on a daily basis.

It might be said that your most important job isn't building software. Your most important job is eliminating ambiguity. What? How? Your job is to figure out a human process - sometimes business processes, sometimes home or lifestyle stuff - and understand it well enough to improve upon that process in some meaningful way.

You can often do that without building software. Whether you build software or not, your task as an engineer is to understand a process and help fix any problems in it. The understanding comes from investigating, being nosy, asking questions, following up, and persistently chasing answers. Some answers will be technical and others human; both are important.

Procrastination is a bad strategy, though. Don't wait more than about 2 days if you're procrastinating a hard part. It won't get easier by getting distance from it; you're likely to just forget what you were doing.

Instead, set a timer for 30-45 minutes, and write out all the things that are confusing you about the hard stuff. It's okay to write out questions that are hair-pulling frustrating and rudely fucking intense during this frustrating damned brainstorming session. Really, it's okay! Just make sure those notes go on paper or into a program that doesn't keep an undo history, so others can't read the impolite version later. ;) So get your frustrations and confusion out in written form where you can see it. Tackling ambiguity is hard work, and emotionally demanding, and it's healthier to be irritated than to be fearful and frozen. Vent the confusion.

Then take 15 minutes for a break. Come back after, and set the timer for another 30 minutes, and write down everything that you do know. Don't skip this part - you know more than you realize about what you're tackling. Get it written down even if it seems obvious. This isn't a research paper and you don't need sources, just write what makes sense; trust yourself.

Take another break. Come back, and re-read your questions. Are there questions you can group together because they're really asking the same thing? Reorganize and condense the questions, and rewrite them professionally. Try to come up with a title for each set of questions. Then come up with a plan for who you can talk to about getting your questions answered, or at least explored more thoroughly.

If you've done all of these steps, you've turned ambiguity and confusion into a list of what you do and don't know, and a list of questions to help you narrow in on what you need to know next. You have a plan for who to discuss your questions with. That's a lot better than a blank page!

Contact that person (or people), now that you're well-organized, and set aside 30-60 minutes to talk. Ask them if they'd like to see your document ahead of time; depending on the topic, it may or may not be helpful for them to read it. When you meet with them, pause to take notes periodically, right back into your list of questions. Then after the meeting is over, reorganize and clean up your doc to integrate the new information, and discover any remaining questions.

Project Management

The art of project management is all about organizing and communicating progress, milestones, and expectations. That can include deadlines, total size and scope of project, and incremental sets of tasks along the way. It can also include ensuring that project requirements and design are sufficiently complete that coding can proceed. Project management is the oversight that helps make sure that things get done.

Rather than thinking about the project manager as a drill sargent, it's more accurate to think of them as the pit stop crew at the car races. They exist as backup to help make sure that the team can keep focused on its primary task.

Team leads and managers know that good results are all about managing energy, and keeping people focused, unstuck, and energized towards a clear goal. Managers get obstacles out of the way, facilitate meetings to get questions answered, and provide a sounding board for ideas and plans. They help reduce the friction in the process. When you're working on your own without a manager, it's helpful if you can find a professional (of any field!) to provide a little of this coaching and guidance. It also helps to have honorary teammates even if they're not coding, so you can celebrate progress together. Even experienced developers rarely go it alone.

There isn't one right way to do project management. The role is best filled by someone who is attentive to everything going on, sensitive to the needs of the team, and willing to tackle whatever comes up that needs smoothing out. It's heavy on communication, planning, and organizing.

When you work alone, you do double-duty, working as both project manager and developer. It can be useful to separate these roles into different blocks of time. When you're making a task list, checking items against it for completion, organizing what order they're done in, and so on, you don't worry about the details of the code. Don't let yourself task-switch. Focus on just organizing. Then when that's satisfactory, be a developer and focus on doing individual tasks well. You can create new tasks as you see the need, but then get right back to the code you were working on. Stay focused. Alternate between these roles throughout your project but not within a short time block.

The task breakdown is your biggest strength when managing a project. You can make tasks and subtasks to group related activities.

  • Create the database tables for my app
    • Create a database user and password
    • Create a table for the CustomerIdentity
    • Create a table for CustomerAddress
    • Create a table linking a CustomerIdentity to one or more CustomAddress entries
    • Create a table for Order
    • Create a table for Product
    • Create a table for ProductsInOrder
    • ...
  • Create a script to add sample data for testing
    • Add data for 3 fake customer identities
    • Add data for 8 addresses and their assosications to each customer
    • ...

In the pro world, these smaller tasks would get an hours estimate for roughly how long they will take to complete. You can do that if you like. If you have trouble estimating time, don't worry about it for now. That will come with experience and when you're doing a lot of the same kind of coding for months, rather than everything being new.

The main thing is that the tasks are granular enough that you can easily measure your progress against them, to see which ones are complete and which are still pending. They should also be separate enough that you can complete one fully without stumbling into working on 3 others along the way. This helps make more organized work and simpler code.

Working with a team or a coach helps remind you to check your progress against your task list on a regular basis. This can also give you a rough sense of how long it's going to take you to complete the whole project.

If your first attempt at listing out tasks turns out messy and difficult to work from, don't get discouraged. This is a skill just like coding is; it takes time to develop. Learn from what was messy and try again. Try writing tasks for the parts of the code you've already gotten done, and see if those make more sense. You can also check in with a mentor or coach for ideas here.

Portfolio Preparation and Interviewing

The best impression you can make for an interview is to present yourself as an accomplished professional, ready to serve their needs, and your work as polished, professional work. This gives high confidence to your potential employer that you can deliver results that meet their business goals. You are the solution to their problems.

Polishing Your Work

Your work speaks for itself. A well crafted piece, with enough depth to show skills, and enough polish to show good judgment, helps them know what you're capable of. Likewise, a shoddy piece that's poorly organized tells them that you either don't take your work seriously, or that your skills need work.

So what makes a polished piece?

The application, even if incomplete, should be smooth to use and should not crash or be obviously buggy. The portion you've completed should work well. If you can have the whole app finished, that's cool, but don't be afraid to show an incomplete app that's well put together.

Get the bugs out. An incomplete app that's highly reliable makes a better impression that one that's buggy. Focus on quality over quantity.

There should be a User Guide being written, even if it's not complete. It should have clear headings, organized sections, and a table of contents for skimming. It doesn't need to be wordy or complex, just something to get a potential user familiar with the app. A video demo is an alternate option, although it's much harder to skim to review.

The code itself should be readable and clear, in case they want to review that. You don't need to print out your entire app's code on paper. A page or two of code sample and a link to your github project url is fine. Providing a sample of your code (for a personal project, not a former employer's project!) is a good choice when you're early in your career, and need to be placed in a role appropriate to your skill set.

Work with your classmates or mentors to get a code review of your code. Provide code reviews to other people as well. Practice improving the clarity and conciseness of your code and your classmates' code. It improves readability and gives you easier to debug, easier to maintain, more professional results. The difference is obvious to interviewers.

Screenshots should be provided so you can talk about your app. Prefer paper screenshots in an art portfolio for this, rather than a live demo; the live demo is too likely to experience technical difficulties and bugs. If you've been working hard on the project, you can lead someone through it from printed-out screens easily enough.

Your interviewers will probably only glance lightly through your work. That's not a bad thing! They have a lot of experience reviewing work and will very quickly be able to tell how skilled you are (or aren't). Once they know that, they can adjust their questions accordingly, and you can continue on in the interview. The interview time is valuable, and they're ensuring you can both get on to the interesting, meaty questions about your future job, rather than just focusing on what you've already coded.

(Ironically, the 'final project' you spent months preparing for your interview may be reviewed in less than 5 minutes - but they will know more about your skills and work habits from that 5 minutes than you might ever guess. Code is very expressive.)

Polishing Your Presentation of Your Work

Practice talking about your project work with others before you interview. Demo your app at least twice, talking about what it does and how it works. If you really struggle to talk about it, practice several more times with different people, or consider visiting Toast Masters for public speaking coaching. If you can talk fluently and easily about how your program works, you will have an easier time answering questions when the pressure is on during an interview.

Talk with classmates about tech ideas. Practice coming up with pseudocode on a whiteboard and explaining it to 2-3 people who are participating with you. Use correct technical vocabulary and use it enough that the words feel natural to say. This is probably the single biggest thing you can do to improve your confidence in the interview process. Being able to talk tech with other developers, including drawing pictures and ideas, does a lot to build real skills as well as confidence.

Stick to one idea at a time. Don't jump around chaotically and get lost on tangents. Show that you can be an organized thinker and an organized speaker. Listen well, and answer the question that's being asked, and then shut up. The interviewer has a lot of topics to get through, and wants to hear your answers to more of them. They're also checking how well you listen and understand, and how well you ask clarifying questions. It's a dialog and a collaboration, not an exam. Stay on topic, but do elaborate when prompted. Again, this is something you can practice with a professional friend, by doing a mock interview, and asking them to pay attention to these particular habits.

Each interview process is different, and you may get more or less time to talk or demo your work, depending. Be flexible and be willing to ask questions about how the interview will go. "How long would you like to spend on this topic?" and "How much depth do you want in this answer?" are very valid and useful questions to ask when you're unsure.

Mannerisms, Communication Habits, and Confidence

Bring a notepad and pen to your interviews. Even if you don't use it much, it presents a more professional appearance because you came prepared.

Confidence matters. Your professional confidence helps your potential employer trust you as capable and organized and ready. Even if you're nervous, true confidence still shows through to some degree.

True confidence comes from being well prepared and knowing clearly what your actual skills are, as well as having accomplished challenging things and knowing that you can. Being excited or nervous is natural, and they know that. Some will help you to relax into the interview so you can give your best performance. Others assume that's your problem and are less overtly welcoming. Whether they help or not, do your best to remember your skills and who you are, and convey that.

Confidence is about knowing that you belong. By the time you're interviewing, you've already had multiple people checking your skill set and agreeing that yes, you're ready. Trust them. Also, trust the interviewers. Their job is to ensure that you are ready for your potential job. They're professionals who know what's needed. They will recognize your skill. Your job is to stay emotionally present and show that you understand their needs and can solve them.

Stand up for handshakes. It makes a better impression and puts you in a more powerful body position.

Sit up, don't slouch, and if your chair is forcing you into a slouchy posture, ask politely for a different chair. You can't use your voice confidently and powerfully if your windpipes are all twisted up from bad posture.

Open your chest, shoulders gently back, head up and attentive. I know this one is trickier for women who may be self-conscious about bust showing. Choose interviewing shirts that don't show any cleavage, to make this easier to feel confident about. You can also layer a cardigan over a dress shirt if button-gaps are a problem. You need to be able to sit up and lean back safely and confidently.

Sitting up with good posture makes it easier to make eye contact with your interviewers, easier to talk freely and loudly (the rooms often have fan noise), and easier to show a powerful listening attitude. It also increases actual confidence as well as perceived confidence. And it makes it easier to breathe if you're nervous. You don't need to be stiff as a board, but really do sit up. Sometimes this means sitting on the front edge of your chair if it's a slouchy chair.

If you have trouble sitting up for 30-60 minutes with a friend, go out walking for an hour a day for a few weeks. Assuming you're not carrying a purse or bag when you walk (which can off-balance you and strain one side), you will naturally build a stronger back and better posture merely by getting some basic balanced exericse.

If you have a multi-panel interview, stand up and walk around between meetings. Even 2 minutes of getting your blood flowing can refresh your mind for the next step.

Greet people warmly, confidently, and be welcoming. They should be welcoming to you as well, but sometimes even if they're reserved, you can warm up the interaction by greeting them enthusiastically. Everyone likes to feel welcome.

Don't let it get to you if your interviewers are very formal and reserved. They're likely to be working from a pre-set script and set of questions, in order to keep interviews fair for other interviewees. Or, they may simply be less trained, and are doing the best they can. Don't take it personally. Answer as best you can, and ask clarifying questions as needed.

Listening well really, really matters. You're here as a professional, applying to be the one to solve their business problems. That means you need to show you hear and understand the problems, and have relevant talent to help solve it. If you do this well, they'll be more likely to be willing to train you even if your skills are low. Do this poorly and they will believe you can't be trained. Listening skills matter a lot. Work on this with friends if you think it might be a difficulty for you. It can be improved with practice.

Jokes are risky. If you choose the wrong topic, you could come across as unprofessional or offensive. If you misread a cultural issue or work context, you could joke about something that others are sensitive about and you didn't even know. You can be light-hearted and warm without making jokes. They're not hiring you to be an entertainer, so stay focused on the professional task at hand. If you do joke, keep it purely to safe technical topics, but realize that even then you could stumble into past context you know nothing about. Keep jokes tasteful and rare.

In the rare case that someone asks you an illegal question (most of which have to do with protected classes such as marital status, children, race/ancestry, nation of origin, age, etc), stay calm, and respond with something like, "I'd rather not discuss that during an interview." You can be polite but firm about this. You can also take this back to LaunchCode to get further advice after the interview is over.

Listen well, be confident and attentive, and be gentle with yourself around mistakes and uncertainty. Your interviewers are probably going to ask questions above your skill level some of the time, so that they can get an accurate idea of your skill level and don't underestimate you. So you're expected not to know some of it. When you hit unfamiliar areas, be frank and honest about it, and focus instead on "here's how I would go about learning that." Don't treat it as an ending point, but as a starting point.

Hearing the Call of a Challenge

Have you ever heard destiny calling to you? Perhaps it was a moment that made your heart sing, or made you curious beyond reason, or perhaps it was a quiet voice that said, "There's more here to discover. Aren't you curious?"

Have you ever been told that something was impossible, that you couldn't do it? Were you energized by that challenge and wanted to prove them wrong? It's another type of call.

Or maybe the call came in simpler words, on a day of frustrated exhaustion: "There's got to be a better way." "I won't let it end like this." "I'm going to live a different story."

The big challenges in life don't just ask us to do something; they transform us. The big challenges change us into someone different from who we were before. They ask us to stand for something, to claim ourselves in a new way. And sometimes, in changing us, they help us change the world.

We don't always answer the call. What keeps you from answering the call to take on a challenge?

I know some of mine. I'm too tired. I'm doing so much already. I'll be alone if I do that. My friends might leave me. I don't have the time. I'm .... I'm not good enough.

But like a bell in the distance, the call keeps coming. I sneak a peek at it around the corner once in a while. We play hide and seek through the what-if game. What if... I could dance like he does? What if... I could speak on stage like she does? What if I had started taking lessons a year ago, like I meant to; how far along would I be now? Ghosts of possibility poke my thoughts.

When have you answered the call to challenge, and taken up the task?

I had a job some years ago where I kept seeing ways that team process should be improved. I dutifully reported these to my manager (he might have called it "complaining"), as well as suggestions on how it could be better. One day, he gave a new response: "Well, can you fix it? I'm putting you in charge of the team." I stumbled for a moment. Me? In charge? I'd... never been in charge before. I'd been fired for complaining, but I'd never been promoted for it!

It wasn't a question. He was putting me in charge. And, I had earned the role. He was only checking in to see how much support I might need during the transition. All of my habitual responses flared up in my mind. I wanted to turn away from the challenge. I wanted to become invisible, to stay small, to not take the risk. I wanted to tell him he'd made a mistake. But... I couldn't. I wasn't convinced that he had made a mistake in choosing me. If I had so many ideas about the wrong way to run a team and the right way to run it, maybe I actually could do it.

He waited for me to get over being stunned, and then we talked a bit about planning for the transition. It took a lot of courage for me, but I stepped into the role and performed it well for two years after. I was a valuable asset to the team and to the company, and I did fix the process problem I had raised, plus several others. I had to grow into my courage in my new role. It took time. But I answered the challenge and stepped up.

And answering the challenge transformed me. I learned that I could be a leader, and a good one. I learned how to speak to a board of directors, and started to learn how to present. My self-concept changed, and I gained confidence in enormous ways in the years that followed.

When you've answered a call to challenge, how did it transform you? Are you still feeling ripples of that years later?

A challenge doesn't end when you succeed at it. It becomes a path, a doorway to greater challenges and ongoing growth. It opens doors in life. It leads you into living a bigger life, more full of the richness of being. It also makes you more available and more valuable to other people, who learn from what you experienced. It enriches us all.

But along the path, there are a few gatekeepers. An initiator invites you in to the path, and throws you the first big challenge along the way. She is the source of the call, the siren song that lures you in, as well as the first wall you'll hit as you try to follow. She needs you to discover that you are capable, and to learn how to get back up when you fall. She will keep throwing hurdles in your path so that you can practice overcoming them. Her name is Dedication.

Persist at the path and improve your skills, and you'll meet another challenger. "You didn't do this on your own," she'll say. "You only made it this far because I helped you. I made the challenges too easy. You're not ready to go out in the world. You couldn't do it on your own. You're not good enough." She's a tough one to get past, but you have to defeat her. Her name is Doubt, and her twin is Faith. You have to know yourself well enough to leave the nest, to move on without teacher. How do you know when you're ready? You'll know.

Pass her by, and you'll meet the final gatekeepers. "Show us what you can do." "Can you really do this?" "This isn't good enough yet." "We need more from you." "We're not letting you through unless you pass a high bar."

This crew holds the keys to the goal, and their job is, once again, to challenge you. Prove your worth. Prove you've got what it takes. Proving yourself over and over is exhausting. But they're actually doing you a favor. The road gets much bumpier after this point, and they're making sure you're as ready as you need to be. They've been there before, themselves, and proven themselves over and over again for years. They know what it is to be out there unprepared. They will hold you back until you're truly ready to succeed. And then, with Faith, like an arrow pulled back in a bow, they will release you to fly.

You made it through the gauntlet of challenges, and faced the panel of interviewers, and passed. You landed the job. Congratulations - now the "real" hard part starts. Now you get to live full-time as the new self you've just begun to understand. It's still hard, but it is rewarding as well.

And then, some years later, you'll realize: not only have you passed this challenge, and some others, but you're ready to go back and help others. You're ready to take on the challenge of passing on your knowledge, and help initiate some new arrivals, and be a gatekeeper to help them decide when they're ready for the next step.

Challenges, rites of passage - they transform us. They change what we are capable of, and often, who we are. They ask us to live for something bigger than ourselves. They demand dedication, teamwork, communication, skill, patience, tenacity. And they make life richer, and help to improve our lives, our communities, and our world.

It starts by answering the call.

image credits