Onboarding Junior Developers

3 months after leaving Hackbright, and I'm still running triage for many of my students who've been hired in the past 6 months. Not that partner companies are mistreating them, or that their skills aren't up to snuff. Most of my triage stems from a lack of real mentorship. Everyone knows that "time-to-useful" with any engineering hire is usually around 2-3 months, but no one really understands what is happening during that time that takes so long, and why some people don't really make it. 

So I'm going to write a book about it.

In this book, I'm going to discuss some of the programs I've seen work, ways they could be better, and most importantly, how to make junior developers useful, quickly, while making sure they understand how their performance actually is throughout the entire process. There will be case studies, research, fun charts and graphs and instructions on how to cost-and-time-effectively hire and onboard junior developers.

But this is a blog post, not a product announcement, so I'm going to drop some insights on you before that. 

A culture of teaching


How many mid-to-senior level developers reading this right now feel like they know everything they need to know to do their job? That they could functionally program without any reference materials, or debug without Google? Anyone who raised their hands probably doesn't work well with junior developers. 

Everyone who didn't raise their hands understands that knowing isn't the important part, reasoning is. Mentorship makes up the space between a productive jr. developer, and an unproductive one. Mentorship mostly consists of style guidance, help in navigating the typically awful reference materials for a given language, and institutional knowledge about the codebase and it's quirks. Junior developers need this, and it's a people skill to be a good mentor. Not everyone is suited to mentorship, but those that are can multiply the output of a junior developer by their own, and end up with much more than either would have produced alone.

Mentors should plan to spend at least 8 hours a week with a junior developer for the first month of their employment, and 5-6 hours for the next two. That's at least an hour a day, preferably in the morning. This should mostly be spent pair programming, or doing an overview of what you expect them to be able to do, and how they might go about doing it. Usually, an honest end-of-day check in is also important, but this can be done over email. Encouraging honesty about what they are having difficulty with is imperative, so that you can give further reading, or explain concepts that might not yet have solidified.


Fostering a culture of learning doesn't end with mentorship, however. Everyone on the engineering team is a learner, and everyone has the capacity to share knowledge. Having workshops and lunch sessions taught by your engineering staff helps encourage senior staff that sharing their knowledge is important, and helps set expectations that it's not just up to them to handle the hard stuff. Teach a mix of beginner and advanced topics, such as explaining how the complex recommendation engine you use works, as well as a primer on your front-end JS framework. This prevents siloing, and also helps jr. developers to feel they can be honest about their actual skill level. You want to foster the idea that you don't expect them to just know, but that you expect them to ask. Junior developers should also be expected to teach, and asking them to explain in depth things you know they will have had to learn on the job will help them with both their credibility and confidence. 

Re-teaching language fundamentals is a good idea- most developers have to learn a new language for their first job, and going over both basic and advanced techniques will help new developers become more effective, faster. You can lean on your existing talent to do this, over lunches and in afternoon sessions, but you may be able to bootstrap it by inviting user groups to put on classes in your office in the evenings. Asking your junior talent to teach things they don't yet have confidence in causes them to investigate deeper, think more critically, and helps others. Having junior talent do a series of short talks that other junior staff is required to attend allows you to parallelize the effort they're individually putting in, as well as give them expectations to measure up to.

Hiring In Groups

Junior developers work best together, in pairs. Hiring a group of 2-6 (or more, if you have the budget and inclination to take on "classes") can be many times more effective. When working together, two jr. developers can more easily ascertain if they need help, learn faster, and have twice the working memory space. When hired together, most jr. developers are net positive twice as fast than when hired alone. 

New developers need someone who they can realistically compare their knowledge against, and who they can freely toss ideas around with. Many jr. developers don't feel comfortable or feel intimidated by other members on their team, out of a feeling that they are wasting time, or their ideas are primitive and too obvious. Most developers probably can remember a time they didn't speak up because they thought their idea was too obvious (and obviously wrong) and so hadn't been covered by the team, only to bring it up later and be told they could have saved everyone a lot of time.

Setting (real) Expectations

Honestly discussing and setting productivity milestones within the first few weeks are extremely important. Understanding what is expected of them in terms of productivity is important, because most new developers will spend most of their time learning the skills they need to accomplish what is expected of them, and they need to know if (for instance) they need to spend more hours at work getting things done, or if they can go home and learn more about the skills their job demands, or if they can rest their brains. 

Realistic milestones are important - if you feel like your junior developers should be blowing away your milestones, then your expectations aren't real, they're just a minimum that you'll ultimately be disappointed in. 

Hiring a consultant

Ultimately, these things are hard to implement. It's tough to look at your existing team, and know who will make a fantastic mentor, what your junior talent should be learning (and teaching themselves). It's hard to know what they'll be capable of 2 months from now, based on where they are now. Hiring an engineering onboarding consultant, or an educational consultant, can be a fantastic option for those running teams strapped for time, or whose teams lack the empathy capital to spend on hours of mentorship. 

Fortunately, consultants exist who can do this kind of thing. I'm one of them (shameless plug) and can help you design an onboarding process, or help your existing onboarding process accommodate developers from a more diverse set of backgrounds than it currently does. These processes can help your existing team save time, identify stars (and bad apples) faster, and help foster the growth of your entire engineering team. 

If I can help, shoot me an email at lizTheDeveloper@gmail.com.

Scarcity and Hackbright - the Top 5%

There are some major parts of Hackbright that deal with scarcity. Our business model (and we are a business) is based on it, and our company philosophy (and we do have one, one that's very important to us) is based around it as well. First, let's talk business.

There aren't enough developers. Not in Silicon Valley, although you can't sit in a cafe without hearing about code or devops. Not in the rest of the world, either. There are nonprofits that need help, terrible industries that need to be automated away (I'm looking at you, medical billing), and information that needs spreading to the bottom billion, so that they can be informed, and more powerful. This kind of thing sounds great, but in order for any of those jobs to get filled, there first have to be enough developers to go around. And there aren't.

There also aren't enough women in development. There are probably a million and a half ways to solve this issue, we're choosing one path. Increasing the number of female devs directly by training them is a great start to help with the issue, as well as solve the scarcity of developers. This brings us to supply and demand, and scarcity. 

We exist because companies can recruit from us. We provide enough high-quality candidates that companies come back to us time and time again. The reason our candidates are high quality is because we train them, yes, but also because we select them from a pool of smart people. Currently, we accept 5% of candidates that apply to Hackbright. Why? Wouldn't it make sense to take more? We're a for-profit company, the students pay us to attend. We're leaving money on the table by not accepting more - we could double our earnings by accepting 10%, right?

The problem here is complex. It's about keeping our quality high - as a company, and for our students. We try to do the right thing for quality first, profit second. Scaling out doesn't make sense if the experience gets worse, or if fewer of our students end up with jobs. The reason quality suffers is because of scarcity.

First, we're doing very emotional labor. Emotional labor is traditionally undervalued, and it's also regarded among the professional world as a limitless resource. If you're a caring person, you should be able to expand that caring to an infinite set of people, right? This is a fallacy - one person can't be the emotional pillar needed from a teacher to as many people as they're asked. Even given that there simply isn't time in the day to do that, we're ignoring the fact that helping someone through something difficult, like say, rewiring your brain to think like a computer scientist in 10 weeks, takes something out of you. It's rewarding, sure. It gives something to you that you can't buy or get otherwise. But it does drain. 

So the emotional labor is scarce - people who can both program, debug well, explain things well, and do the emotional labor are scarce, but the biggest scarcity is people willing to do that labor. This labor is traditionally reserved for significant others, friends, your children, your family. When doing this work, students often replace your friends and family, become as significant to you as your children. You have to be willing to do that to at least a limited extent, and most people aren't, or at least not for long. 

The next scarcity is space - simply having enough desks and pairing stations in a city like San Francisco is both expensive and hard to find. Keeping everyone together as a cohesive class unit is also tough. 30 is probably the maximum number of people that could function as a class, especially because being a part of the class is such an integral part of Hackbright in general. We can't just upsize the class, we'd have to create an entirely new instance of the class - with lead instructors, assistant instructors, a new group of mentors, et cetera. 

The last scarcity is absorption. The bay area needs more developers, but has a limited capacity to absorb new junior developers. Everyone who comes out of any intensive is essentially a "prepared beginner", who, through their own curiosity and drive, as well as a bit of help from a senior developer, can add functionality to software projects, run tests, debug, and make modifications. They're not yet capable of designing a project that scales, or spinning off an entire feature branch without much help. They do consume resources when they join a company, although the company gets a net gain. After about 3 months, all of our students are major contributors in whatever teams they join, but it does take that 3 months. We release 26-30 new candidates quarterly, and they've got to go somewhere - there are a finite number of jobs even for perfect candidates with the exact right stuff.

Why does Hackbright only accept women into the program?

Another blog post transcribed (thanks @rebecca_standig) from the same conversation about @Hackbright Academy. It also covers some hostility I get from people about our policies.

EDIT: changed "where all but about 80% of women" to "20%" - that was a mix-up on phrasing. 20% of women who start in comp sci degrees finish them.

Note: Hey Hacker News readers! I'll be publishing something on pedagogy in a bit. Stay tuned. 

So, why do you admit only women to Hackbright?

I've gotten this question really often via email, as well as at coffee shops and any time that I walk around the Mission or SOMA in my Hackbright Academy t-shirt. Often, people ask me why we only admit women. They say things like, "It's discriminatory. Aren't you trying to fight discrimination?" Or they say, "You can't just admit women. That's illegal." Or they threaten to sue me. People think that they're very clever.

The reason we only admit women is because as it stands, we put more women into software engineering in one semester than Stanford and Berkeley do every year. Women start a computer science degree at maybe 1/3 the rate as men. Then there's this freshmen drop-off, where all but about 20% of women end up changing their major, usually to something involving design or business. Sometimes, they go into electrical or mechanical engineering, but that's actually pretty rare. Usually they leave the field of engineering altogether.

I have a theory about why this is. During a computer science degree, most women don't have a lot of friends to turn to who are also doing a computer science degree. Most computer science education is heavy on theory and light on implementation. So, you learn a lot about computer science, but you don't really learn how to code. That is something that you have to do on your own. Since [these women] don't have friends that sort of expect that of them and know that that's what they're supposed to be doing, they don't spend a lot of time in it. If you don't spend time implementing theory, you'll never really understand it. The courses get harder and harder, and they haven't spent a lot of time with their friends talking about these kinds of things. They're surrounded by people who are not like them, and don’t openly talk about struggling to learn [difficult programming concepts]. This reinforces the idea that they don't belong there, and is a common fear. All the time, women tell me that they feel like they don't belong in computer science, or they don't belong in engineering, or they don't belong in a company as a programmer.

The reason for that is there aren't many women, and that begets even less women wanting to get into computer science.

So, what’s the solution?

So what do we do about that? First, we create a community. There are lots of communities for women. I know this because I'm a woman in tech, and I am inundated (especially as a leader of several general organizations for women in tech) with people telling me all about all of the different organizations. The problem is, I meet 4-5 women every week that have never heard of any of these organizations. So outreach is a problem.

The next problem is that it's intimidating even to join these big organizations because they're for people who profess that they are software engineers already. Sometimes, they're about being software engineering majors or computer science majors, and that helps. But they're campus-specific, so if you're in college that's great for you.

Most women who get into computer science that I interface with are doing so after they've already completed a degree in some other area, be it business, marketing, biology, chemistry, sometimes journalism. There are a number of things that drive people away from those fields and into software engineering, or just drive people away from software engineering initially into those fields and then they realize that this wasn't what they wanted.

These are the people that most often make really amazing software engineers, yet have no real path into software engineering. They're not already software engineers, so they don't feel like they can join these organizations, but they're also not going to college for software engineering, because they've already gone to college. It would be ridiculous to expect them to go and get another four year degree or a two year master's degree that they may be ill-equipped for. So these are the people we serve. They're a minority that needs a leg up. Just like having a foundation that helps Asian Americans or Hispanic Americans or Indian Americans get a leg up in an unfamiliar place, a place where you are underrepresented and generally marginalized.

That's why we serve only women.

So, what about the people who think you “have to” admit people?

We don't have to admit people. We're not a school that is accredited by the US Board of Education, nor are we a non-profit. We are a for-profit company, but we're a for-profit company with a mission.

That mission is to bring equality to computer science. Our strategy for doing so is the following: One, only let in people who will contribute to equality in computer science. Right now, the smallest subgroup of people in computer science is women. Other than, potentially, transsexual people. They're a small enough group, though, that if we were only to serve them, I think we'd go out of business. Women make up half the population on the planet, yet only about 6% of computer science engineering jobs.

The second thing that we aim to do is promote the idea that women are competent in the field. They are smart and useful, and just as smart and useful as men, and should be taken seriously. Rather than admit literally everyone who comes in, we admit the top 5% of our applicants. Now, these might have been people who would have gotten into computer science some other way, and that's great. But what it does by producing a candidate of a consistently high quality is further promote the idea that women are just as competitive as men in computer science. By putting out really excellent women into computer science, we reinforce a positive stereotype. Stereotypes are not all bad; positive stereotypes are great. We would love to reinforce a positive stereotype, which will help combat all of the subtle biases that work against women in computer science.

The last thing we do is make sure the insecurities and vulnerabilities that causes women to leave computer science in the first place are patched. We do some drills in the safety of Hackbright on whiteboarding, on salary negotiation. We do some generalized therapy, just by talking out insecurities and fears. We get very involved in their emotional wellbeing, because it matters a lot. The most productive software engineers aren’t afraid all the time, or down on themselves - they feel empowered. So, we do our part to empower our students.

What do I look for in a potential Hackbright Student?

I had my cousin transcribe the following conversation, which answers a lot of the questions I get asked during interviews. I went through and added a few links to it, but it's generally unedited- it's just how I talk with the "um"s and "uhhh... [long pause]"s taken out.

So, what do you look for in a potential Hackbright student?

I get asked that a lot, actually. What is it that makes us see a person and say, "Yes, we're going to admit them into this program and ignore 95% of people. But this person, yes, we believe in them." The answer is simple. But the backstory is a little more complex.

Salon recently published an article called "School is a Prison - and Damaging Our Kids." It is. That's the biggest problem. School, as an institution, was created to teach children how to not question authority, and how to crush their own curiosity for the betterment of absorbing someone else's ideas. It is mostly about causing someone who might otherwise be compelled to learn whatever they wanted to on their own to instead accept what they're being taught. This system worked really, really well during the Industrial Revolution, when the highest demand was for low-skilled factory workers. Today, that’s not the case- knowledge worker jobs are on the rise, and are going unfilled, but not for the reasons you might think.

One of the biggest things that our school system does today is cause people to start thinking like factory workers. They start questioning the audacity to want certain things, like respect in their field. They stifle their own thirst for knowledge and think, "Well, I don't need to know that. I only need to know certain things - things I've been told that I need to know in order to get a job, or have the life I’ve seen on TV."

What we're looking for is somebody who was terrible at that kind of thinking. We're looking for somebody who isn't very good at being told what to do or doing what they’re told. We're looking for somebody who is actually often bad at school and bad at listening to directions. Instead, what we look for is someone who is very good at following their own thoughts about what it is they want to learn.

Now, usually someone who has always decided to follow 100% their own thoughts and feelings about what they want to do isn't what we're looking for. What we're really looking for is someone who has had to fight that system so hard and so long, and had no help doing it. What we want is to be that help. I say this to people often: "I take people that were always meant to be software engineers, and I rectify that mistake."

That's sort of the secret of what we're looking for at Hackbright, but often times the reason these people aren't software engineers is because they're just no good at identifying the fact that they should be software engineers. So, don't think that just because you think that you aren't a software engineer deep down inside that that means you can't be a successful Hackbright student. What we're looking for is somebody who fits the philosophical profile of a Hackbright student.

So then what’s the philosophical profile of [a Hackbright student]?

Well, the philosophical profile of a Hackbright student is somebody who is curious, is uncompromising in their search for answers, who has a questing approach to truth rather than an accepting approach to truth, and has a natural affinity for systems. They have an affinity for logical systems, for mechanical systems, for how things work. This often means biologists, but it also means mechanics, and it means people who are interested in law. We have a positive correlation with law a lot. Chemistry, physics, math.

The biggest thing that is often found lacking in people who would normally correlate  really well with being a Hackbright student, people who sound great, is the “why” factor. Why are you doing this? Why do you want to know? Why have you done everything else in your life? If you ask that question on a constant enough basis, it leads you to act a certain way. That's what we're looking for most of the time, when we ask you all about your background. We want to see evidence of you asking why. We want to see evidence of you looking at what you're doing, looking at the world you've gotten yourself surrounded in, saying "Why?" and in some cases being unable to answer that. That’s when you have to jump ship- to change what you’re doing. We see half-finished degrees and projects abandoned a lot. A lot of people are leaving what they thought would be their dream job to come here and change their life.

Jumping into a situation is the only way to really learn about it. By asking why, that shows that you've learned about it, you've sought out enough information to understand where you are, and to get to the point that you can critically assess whether or not you're in the right place. If you can critically assess that you're at the right point, you're fine, and you probably won't apply to Hackbright. If you do apply, that means that you've decided that you aren't. It's not about the money, although money can be nice. It's not about doing something fun every day. It's about questing for that fundamental truth constantly, as sort of the driving force of who you are, and being unsatisfied when you aren't there.

Maybe They Know

It strikes me recently that perhaps some of the people who have been running universities for hundreds of years might know what they're doing.

Christian, David and I have been working on basically reinventing the wheel in terms of what universities do for computer science students. This has been met with tremendous success, but at the near cost of our sanity and capacity to do anything else. We've successfully led 30 people through a computer science education by the hand, which is something universities don't do. 

Universities expect you to handle your own shit. They're as involved in your affairs as you involve yourself in theirs. They don't check up on you when you're quiet. Professors typically don't notice when you don't understand something, and stay into the night drilling you on your data structures. Basically, they expect you to figure out when you need help, and also expect you to force someone to help you. 

Our students are always type-a enough to be able to seek help in class, or for that matter in a workplace. However, they're new to a field that's so deep and frankly, lovecraftian in it's crazy hidden unknowns - they don't know what or when to ask. They don't know who to ask. They start out not even grasping the depth to which they don't understand.

Needless to say, we spend a great deal of time enumerating the order of magnitude of knowledge they're missing. 

The gulf however, drives Christian and I to spend 14 hours a day here. We even have a rule, we're supposed to leave at 6 on alternating days. Neither of us follow that rule with any kind of regularity. Generally only when we're expected to be somewhere. But, on the plus side, our students completely floor our partners on hiring day, and their managers come first review.

Rarely, but it happens, I envy the life of a professor - I wish I could be as aloof and more detached than I am from the success or failure of my students. But, I'm doing something that matters. So many people can't say that. I also suspect that most professors develop that detachment over a great deal of time, and heartache.

Week 10 Roundup

Well I certainly didn't keep up with blogging through the 10-week rollercoaster that is HackBright. I learned, laughed, cried, went through crazy emotional times, and made friends. I also drank a lot of alcohol. 

Week 2 was a blur, mostly lectures in which I trolled Christian to make sure certain points got across well, and to keep him human to our students, rather than some kind of job-bestowing godlike figure. I don't know that I fully succeeded with the second one.  We did a lot of breakout sessions, which I feel like were really helpful. They helped keep each lesson in context so that everyone understood that we may have been doing simple things, but that those things built up to me big deals.

Week 3, my son came to visit. By that point, our students had formed a bit of a bond with me, so me being not there was not too bad for morale. It was however, really tough on me, because I brought him in to work 3 out of the 5 weekdays he visited on. He enjoyed himself enough, and ingratiated himself with most of the students pretty well. Christian showed him the roof and talked to him about physics, which made him instantly reverent. It was pretty cute. 

Week 4, I was playing catch-up, in terms of energy (9yos are very tiring) and in terms of where everyone was in the program. I also stopped making progress on the project I was working on at this point - students needed too much outside help for me to spend time on it, so I was forced to just kind of back off. In the middle of the week, Donglegate came to a head and got really nasty online. Like many women in SV, I responded emotionally to the threats Adria was getting, especially as she's a friend of mine. Due to complexities and traumatic events in my past, seeing some of the images posted online and the vitriol spewed at her, I was emotionally drained and very upset for some time after. Even now, it's tough to write about. At some point, I'll post in detail on this.

Week 5 was a blur - bringing people up to speed on common web technologies and the idea of markup was a big deal. We explained HTML and how it was like Markdown or Wiki Markup, only with a lot more eccentricities helped them deal with what seemed like an impenetrable world. We covered a slight bit of CSS, and then I got to delve into JavaScript. At this point, my energy from the kid visit and ensuing trauma, plus 18 hour days were beginning to wear on me. The lesson I learned here was that we needed more instructors, and that I cannot take time off during Hackbright, or have visitors. Downtime is going to have to be the only time someone can come to SF to see me. 

During Week 5 we also began preparing for projects. We had to very explicitly state that we're not an accelerator. We're not an incubator. We're not here so that you can develop an amazing product vision and start a company. Our students are here to program and to learn things - you can't do that if you're worried about the marketability of a product. Sure, learning happens better when you're solving a specific problem for yourself - when you listen to a lecture on SQL and can imagine using it to solve the problem of how to get two rows of data to JOIN together, it makes sense. If you talk about JOINS in the abstract, it kind of sounds like a crazy, useless concept. So it's useful to have a project you're excited about - but focusing on becoming a crafts[wo]man means you have to focus on the craft, not the business. They're two separate disciplines, and we're not here to make companies, we're here to make developers.

Week 6 was the official start of projects - students were finishing up the final tutorials that would show them how to use SQLAlchemy. Many wouldn't end up using that kind of thing at all for their projects, but understanding the principles behind an ORM is important, because they're more than likely going to encounter them in the wild. 

One thing I wasn't prepared for was the scope of some of these projects. We had webapps of varying complexity - some that had to keep consistent state between two people, some that used multiple APIs and a lot of data, one even used single value decomposition to intelligently rate movies on millions of rows - dealing with datasets larger than the RAM on your computer is not a simple task. But the next tier of projects, things I've personally never even done (although, this does not mean I won't try), things like database engines that handle concurrency, written in a language we didn't teach, using concepts we didn't teach. Things like compilers, lexical parsers, people writing their own programming languages. 

We had a student who read a paper on someone who found correlations between genes and characteristics that had never been noticed before by doing Natural Language Processing on Pubmed papers. This paper kind of contained some abstract notions on how you might do this, but I watched her tear the paper apart, and put it back together in python. It was amazing. Her twitter is @cadeparade, and she's still for hire as of me writing this (but probably won't be for long.) I also got to learn a bit about Part of Speech Processing - which is incidentally really cool.

I had to mention at least one of them, not to show favoritism, but I feel like what happened wasn't real. Like it was somehow removed from the real world. It was like I was out of the country for 10 weeks, and my friends and family kind of watched this amazing thing occur from my excited tweets and late night rushed updates by phone. But it wasn't. It happened right here, in San Francisco. 

Tonight, some of them got offers, which were beyond anything I expected whatsoever. I have no doubt that every single one of them is employable, and would contribute a lot to the organization they end up at. Plus, I have 26 new best friends. 

In 4 weeks, I have to start all over again.

Week One

Week one down! 

It was all very exciting. I got up in front of 26 adult women, and explained that they might have trouble with logic when Aunt Flo comes around. Gutsy, but someone needs to talk about this stuff. 

I was pretty sure that I'd only connect with about half the class, and the other half would hate me. Turns out, I haven't met anyone in the class I wouldn't be friends with. Everyone seems interesting, with varied backgrounds and responses to the material.

One of the most difficult things I've found is the pairing. It takes the burden off of the instructors by forcing students who otherwise wouldn't know where to start to talk out their thoughts. It also makes for a VERY loud classroom, which can be stressful for some of our more introverted students. The other challenge is that it turns out that women like to talk to one another. A lot. While this is a boon for engagement in the material, and for productivity, it's a bit distracting and it's a constant roar of "Ohhhh I get it" and "What? Why won't this work?!". Still though, it seems to knit the class together.

I seem to have a pretty good rapport with Christian - he knocks on Javascript (which is secretly fine) and I knock on Python (Tuples are stupid), which the class enjoys. We've deliberately chosen skeptical, intelligent women who wouldn't take everything we said to be the word from on high, so the back-and-forth is nice. 

All in all, I am exhausted. But I haven't been so excited for Monday in awhile. 

Ask Questions

I've been teaching programming for Girl Develop It now for about 3 months. I've been loving it, because I'm secretly a teacher deep down underneath my programmer shell. If programming is my ethnicity, teaching is my calling.

 The unexpected benefit of teaching has been to help my own confidence when coming to a part of the country so steeped in engineering talent that you feel you're the only one who might have to ask a question now and again. I've realized the tricky bit about asking questions, however. It takes an enormous amount of confidence. 

Admitting that you don't know something, or don't quite understand it is really difficult. You feel that it calls into question things you DO understand. The problem with this, and something you have to remember when asking whether or not you understand something, is what the baseline for "understanding" actually is. "Understanding" means different things to people in different stages of their careers. Depth is a very relative thing(xkcd link) - something that's deep to you isn't deep to someone who's entire life revolves around a narrow slice of your profession.

Last year, Simon Collison wrote a piece called Maturity and the Weight of Learning. In it, he discusses a number of topics- namely, culling and surrendering, and the immature view of tools. Many young developers start with a host of very powerful tools, and so learn web development (and other forms of development) with a "top down" perspective. These tools make you feel powerful, and they abstract away the need to understand how they work - but they are built by human beings, with faults, and break down around the edges. Leaning on them in the beginning is fine - but as you get out towards the edges of the Kingdom of CRUD, you start to notice a need for you to get to your feet in shifting sands. It is here that most developers grow their wings- or turn back and toil in the overcrowded kingdom.

Simon's piece talks about the responsibility we have as craftsman, to learn, to ask, to be ashamed we used a tool without understanding how it worked. This is hard, but it is doable. It is part of accepting the mantle of craftsman - this title is not free. The prescription is to admit your own limits - knowing where they are is the first step to breaking them.

A final note - I assure you, those who have taken upon themselves the title of craftsman, and who are considered so by their peers will never look down on you for trying to learn. Ridiculing someone for not knowing a thing is the biggest indicator of personal insecurity. 

Knowledge is Relative

As a mentor, I spend a lot of time calming people down. This is I suppose my mother hen approach to mentorship, but it seems to work for the subset of people who I take on. I wrote a letter to someone who feels recently like she's failed because she doesn't have a firm grounding on the basics of what she's trying to learn. She doesn't see the progress she's made, or the ground she's gained- she only sees what she doesn't yet understand. I've written this letter to many people in the past, and I suspect I'll write it many times in the future. Here is what I usually say, more or less, with the identifying bits left out.