Ad

Friday, September 27, 2013

[Featured Guest Blog] The top 10 reasons why people stall out learning to program - by Tony, founder of Hack Reactor

Biography
Anthony Phillips is the co-founder of Hack Reactor, along Shawn Drost, Doug Calhoun and Tony's brother Marcus, who works at Twitter; they are figuring out how to teach people to be developers through intensive web development bootcamps. A short official bio:



Tony knows what it is like to be in your shoes. After spending years as a director and lead teacher of a language school in South Korea, his brother (Marcus, twitter) convinced him to quit his job and move to SF to become a software engineer.


Tony did every self-guided tutorial online, and within 4 months was able to land his first developer position. However, he quit to join the inaugural class of Dev Bootcamp. After finishing the program, he stayed with DBC to develop software, help students learn to code, and organize admissions.
Tony on Quora
Hack Reactor - JavaScript-focused web development bootcamp
Tony was kind enough to share his email at the end. Feel free to reach out to him! : ) Great opportunity

Interested in doing a guest blog post? We are excited about what you have to say, message us.

Codesum, previous posts about Hack Reactor
~ Curriculum interview and more
~ Curriculum and student projects
~ The Human Factor of Hack Reactor : instructors and time

Today's news in the beginner tech learning communities:
~ Find out more about how to get started with various technology by joining our online community ABCamp  today's content how to get started developing for CRM at Hackathons

~ Treehouse now has a class on Git
~ Code School now has a class on JavaScript
(please use our referral to support this blog)


Actual Content of the Blog Post

The top 10 reasons why people stall out learning to program

We see a lot of people who are learning to program both during our course and in the interview and pre-course periods.  Everyone finds a certain part of learning to program challenging, but we have noticed that some people fall off the interview schedule or struggle in the class and there have been some trends in the pitfalls that we see people falling into. 

I'll try to outline strategies for staying away from these pitfalls below, but some of them are just hurdles that need to be overcome with brute force.  As someone who has been through the immersive programming education process, I have found the reward of learning to program to be so great that I hope to smooth the road for people who, like myself, were mired in unnecessary anxiety.

1. “Why can’t I get this?”
           
The number one thing I discuss with struggling students is how much time they spend thinking about their status relative to the rest of the class or the rest of the world.

 In extreme cases, some people are spending half of their days dwelling with others on the bleakness of their understanding, or beating themselves up by pondering, "Maybe I can’t understand this.  Why can’t I pick this up as fast as other students?"

            There are two problems with this. The first is that it's depressing and these students tend to have a self-reinforcing downward spiral of anxiety. This can lead to people deciding not to work on programming for a particular day because it is so associated with the negative energy of 'not getting it'.

            The second is that it takes up time. Frequently I notice that people in this situation would probably be on track if they would simply take the time they spend worrying about not being on track and reallocate it to working on the code they are struggling with. This is frequently a very difficult task for this group of people because this particular line of thinking is their go-to thought when they don't get something.

            SOLUTIONS:
           
a.  At Hack Reactor, we tell people to completely rely on us to tell them if they are not doing well and need to worry.  We keep track of whether they are making good progress or not and ask that they spend zero brain cycles on figuring out if they are failing or succeeding, ahead or behind.  If you can find a mentor, have them do the same thing and check in with you once a week. I would suggest having them take on this responsibility and let yourself have a vacation from worrying.

            b.  Get a win!  Frequently people fall into this line of thinking when they are struggling with a problem.  Sometimes just putting down that problem and doing something you know you can succeed at will put you back in the right frame of mind.  Find a task in your project that you know you can ace or do some easy toy problems that you found on the Internet.  Either way, you will keep yourself from starting the downward spiral.

2. Guess-and-check debugging

            People who do not apply a process to their debugging will frequently find themselves very frustrated and assume 'she/he is not meant to program'.  One symptom of this problem is when a student cannot tell where the exact problem is, but is changing the code.  For example, sometimes students will get an error message about a method being undefined and will start to look up the correct usage of that method and tweaking it over and over again, without walking through the code and finding out where their expectation departs from reality.  Sometimes they continue to tweak their usage of the method, when in fact the problem is that the object they are calling the method on is not even the object they expected.

            It happens to be the case that applying a very procedural approach to isolating exactly where the bug is makes a programmer’s life not only easier, but more straightforward.  Building this process is something that each programmer has to do for him/herself, and there is as much art to isolating a bug as there is science, but continually working toward a process is a must for any newbie programmer.

            SOLUTION:

            a.  Force yourself to isolate bugs to a specific line, specific function, or specific area.  Only allow yourself to build a hypothesis for how to solve the bug when you have isolated it as much as you can.

3. No actual building

            One thing I hear all the time is that people are spending a lot of time learning, but not making progress.  In interviews, people will list out all the things they have done to learn on their own, and for sure these activities add up to a significant number of hours. 

However, when we actually start coding, it turns out the person cannot even write a function definition.  This comes from spending time passively taking in information without truly applying it.  It can feel like you understand what you are learning, but when you are forced to do it on your own, you may realize that you are actually completely dependent on the system you were learning from to hold up your understanding.

            This is one of the reasons that we use CodeSchool as part of our pre-course curriculum.  It has the passive learning piece that gives you the context to understand what you are doing, but then it very quickly asks you to do something with the knowledge, and you have to actually switch gears into doing mode.  The more doing the better.

            SOLUTION

Make sure your learning focuses around doing.  I suggest creating some project along side of your learning and constantly applying your learning to that project.  Do not count watching videos or doing exercises that have leading hints as progress unless they are accompanied by actually using the new concept to program/code something that works.

4. The Buddy System

            This one isn't so much a suggestion of what to avoid as it is a suggestion of what to attain. Get yourself a buddy. You will find yourself working much harder and you will be much more accountable if you simply find someone to meet with once a week and agree to having accomplished x,y,z by that time.

            Go a step further and pair with the person once or twice a week and you will see significant improvements.  Try to figure stuff out together and throw ideas back and forth. Coding can actually be an amazingly social activity and it can be very enjoyable and motivating to work on a project with another person.

5. Nail down the basics

           It can be incredibly frustrating for beginners who try to solve a problem, believe that their ideas are just not quite right, spend hours reworking their code, only to find that they were missing a parens somewhere or some similarly simple syntactic mistake. I think a lot of people start off losing efficiency in this way because they want to 'jump right in' and they don't want to lose time with less interesting tasks like memorizing syntax.
 A student ends up losing significant amounts of time trying to hunt down their minor syntactic mistakes and it detracts from the interesting stuff: conveying your ideas through code.

            SOLUTION:

            We recommend that beginners straight up memorize certain bits of syntax.  Go find a style guide somewhere on the internet and model your syntax after that style guide.  Make flash cards with 'iterate over an array called numbers' on one side and
                        `for(var i = 0; i < numbers.length; i++){
                                    //some code;
                        }`
on the other.  Then quiz yourself when you are bored or over breakfast and see if you were missing a `var` or your indentation was off and keep trying until you can write a for loop without even using your brain.  For the simple building blocks of programming (loops, function declaration, assignment, if/else, etc) it is better to know them to the point where you are on autopilot writing the skeletons of these building blocks and then filling in the meat of them afterward.

6. Trying to do things ‘the right way’

            This one is pretty self-explanatory. Many people see coding as a math problem, where there is a right way and a wrong way to any given problem or implementation. It's actually closer to writing in any other language than it is to math. There will be trade offs to any implementation and very senior engineers frequently argue over the merits of one implementation over another.

            SOLUTION:

            For beginners, just let it go.  Make the thing work how you want it to first, and then go back and refactor it to make it better. The wheel-spinning that happens when you try to conceptualize the problem perfectly before dedicating one step toward any implementation is highly inefficient.

7. Lack of a roadmap

            There are so many different things you could spend hours and hours learning. It's easy to go down rabbit holes and find yourself learning about bitwise operators when what you should be focusing on is how to put together simple programs. As you continue to add to the stack of things you have to read, more and more tabs build up in your browser. Eventually you get tired and decide to call it a day, not having even finished one of the small features you set out for yourself when you sat down. 

The skill of catching yourself right before you are about to embark on a learning adventure that will waylay you for 3-4 hours is something I have been building for a long time and still have not got a great handle on, but I get better at noticing when I'm about to depart from the task at hand. I try to stop myself when I notice it is happening.

            Another aspect of a roadmap is where to aim yourself. You could learn Backbone, Ember, or Angular, and that's just for front-end frameworks. Once you have a certain set of skills nailed down, knowing what the next logical step should be is rarely clear.

Knowing when to build a big project and really invest in it or when to iterate over a bunch of little projects to solidify your skill set is tough. Knowing which framework is going to make the most sense based on what you have learned so far is similarly difficult.

This uncertainty can lead to people spending hours on topics they need to eventually know, but don't need to know right now. It can mean they end up with a skill set with large holes in it.

            SOLUTION:

            If you have found yourself a mentor, it is a great idea to have them sit down with you and lay out a roadmap of technologies and concepts to learn and in what order.  If not, it's a great idea to go to meetups and ask developers what they think. Write it down and try to follow it as closely as possible, allowing yourself to be pulled off the plan only when it’s super fun and energizing.

8. Yak shaving

            Sometimes there are major roadblocks that beginners run into that are only tangentially related to coding. Sometimes what stops them from making progress is that their version of ruby is outdated and installing a new version is a major project because the compiler in OSX changed recently.

Sometimes they can’t get their database to set up correctly because for some reason the permissions have been set incorrectly. These problems are useful to learn how to solve and are important eventually, but I would argue that learning them can be delayed for a long time without too much damage, and that a student should avoid dealing with them as much as possible while they are a beginner.

            SOLUTION:

            Have a dev friend/mentor set up your dev environment OR go to a meetup and offer to buy dinner to the first dev you meet if they will help you set up your dev environment. I know this sounds like avoiding the problem…and it is!  Try to spend as little time doing things other than coding as you can. Later (probably when you buy your next computer) you can endeavor to set up your own dev environment.

9. Persistence and speed in debugging

            Students who are debugging a problem with their code will frequently have tried two or three strategies by the time I sit down with them.  This is great, but usually it has taken them too long to get through those two or three strategies.  They usually think that I will have some sort of intuition that they do not have and will see the problem immediately.

            However, what actually happens is the first two or three strategies that I have for how to find or fix the problem are exactly the same ones that they tried, but I do it in a fraction of the time. 

I don't think this is due to me knowing more than they do in most cases, I think it is due to both a process that I have for how to debug and a familiarity with my tools so that I can use them quickly to diagnose. 

For example, the fact that a student might use the mouse to click on the browser and then move the mouse to the refresh button and click on it to refresh their tests and then scroll down to where they have a failing test can make the whole process take up to a minute just to get some data back to help diagnose the problem!

 This process for me is as fast as 2 seconds because I use keyboard shortcuts to move to my browser and refresh. This may seem trivial, but when you add up the number of times that you need to move from browser to text editor and back, it can be very significant.

            SOLUTION:

           When debugging, do not get at all discouraged if your first hypothesis did not solve the problem or if your first five hypotheses did not solve the problem. Keep iterating and try as many different ideas per minute as you can while gathering as much data about the problem as you can. In addition to this, invest some time in shortening the loop between your text editor and your browser. Learn your tools and get to the point where you can move around your dev environment very quickly.

10. Find the thing you love

            Sometimes people give up because they wind up thinking "programming just isn't for me." It may be the case that programming isn’t for some people, but we have seen a good number of people who started off feeling that way, and then they started learning back end stuff, or they started learning front end stuff, or they started learning algorithms and their view on programming completely changed.

 Programming takes a significant down payment up front, and then there are lots of different directions you can specialize in. It's a great idea to try to find the topic that interests you most.  You may hate every minute of CSS/HTML that you have to work on, or you can stay up all night trying to make your algorithm slightly more efficient.  Once students find that thing or those things, they usually hit an inflection point and their learning accelerates and they become much happier.


I hope you found some tips in here that save you hours, days, or more of inefficiency in your adventure to learn programming. I would love to hear other pitfalls that people have observed and how they overcame them. Feel free to email me at tony@hackreactor.com for clarification on any of these points or if you have questions about your own adventure learning to code.

Tuesday, September 17, 2013

Hacking the Learning Curve, Deep and Effective Learning applied to learn Web Development

Myth or Truth: you have to be good at Mathematics to learn to program? Or use technology? Join our San Francisco meetup meeting to find out!

Myth or Truth: you have to be a uber genius to learn how to code? Or use technology? Join our San Francisco meetup meeting to find out!

Myth or Truth: I don't like my high school / college science classes, I must hate computer science and technology? But you love iPhone! Join our San Francisco meetup meeting to find out!

Myth or Truth: I love Mindcraft, but I can't code, so I can never write my own game, truth or myth? Join our San Francisco meetup meeting to find out!

This will be the last post about the Google Hangout presentation on Wednesday about Getting Started with Web Development, hack the learning curve. It's an initiative from the online community that I am starting. ABCamp

I was fortunate to meet many beginners in technology, through Codecademy.com, Crunchies, Women Who Code (San Francisco), Girls Develop It and social media. I was able to collect qualitative colloquial research data from them to understand the challenges, obstacles and the environment. Thanks to "bad" influence from Freakonomics, I am determined to use my economics background to solve and hack some of these issues. I am borrowing cognitive power from Scientific American Mind too.

During this Google Hangout presentation, I want to cite challenges, solutions, motivation, and learning strategies that I have collected so far, share with beginners. The goal is to make learning web development basics more fun, less daunting, have more affinity with their current career, so they don't have to take a jump like I did from consulting career, they can pursue both a business and a technical career. It is especially important for me to present how to use technology to enhance job seekers' skills and opportunities to get hired, improve the productivities of those on the job. It's a win win. I have seen many qualified candidates, missing just one technical stroke when they are almost able to get a great job. I have seen many older employees or employees who have been loyal to their field missing out on the overall job opportunity. They get locked in, pigeon holed, then one day, they may even lose their only job. That's unfortunate, and not the way to go.

Check out the meetup here, remember to sign up for the Google Hangout via Google forms. This meetup is only hosted live streamed, not in-person.
http://meetu.ps/208sPg

Sounds like a lot to cover but actually it is simple. There are a lot of tutorials out there, I just need to show people what are the shortcuts. Then they can always seek experts in each field. Getting started is the hardest.






Sunday, September 15, 2013

Myth or Truth? Questions to be answered at the 9/18 San Francisco meetup Getting Started with Web Development

Myth or Truth: you have to be good at Mathematics to learn to program? Or use technology? Join our San Francisco meetup meeting to find out!

Myth or Truth: you have to be a uber genius to learn how to code? Or use technology? Join our San Francisco meetup meeting to find out!

Myth or Truth: I don't like my high school / college science classes, I must hate computer science and technology? But you love iPhone! Join our San Francisco meetup meeting to find out!

Myth or Truth: I love Mindcraft, but I can't code, so I can never write my own game, truth or myth? Join our San Francisco meetup meeting to find out!

Join our meetup next wednesday to find out. San Francisco welcomes you.
http://meetu.ps/208sPg

Promotional slides are available in draft forms. More content will be delivered : ) ABCamp is a free online content distribution network that provides support and resources for beginners learning technology.

http://www.slideshare.net/dilyssun1/getting-started-with-pr

Saturday, September 14, 2013

Women in Technology: Why the Discussion Now? TechCrunch Disrupt Ignites Serious Conversations

Did you know that TechCrunch Disrupt has ignited serious gender gap conversations at tech conferences? For the first time, the tolerance of sexism on stage is getting marginally low. Join the discussion on our online community ABCamp. Let's see what founder experts and NPR take on this gender climate change at one of the biggest conference of the year. Remember Richards who got fired for tweeting pictures of jokes making brogrammers? She speaks out too.

What do you see as the future of women in technology and geek women?
https://mightybell.com/communities/ab-camp/discussions/334385
ABCamp Discussion on Women in Technology, NOW

ABCamp is a newly established online community that supports beginners and newcomers in technology, and those who are switching fields, learning new modern web development and data technologies. We will also cover web design and product development.

Please join if you are beginners who seek knowledge and support.
If you are an expert, we need your support to bring beginners onboard too!

Friday, September 13, 2013

Women in Tech: How Would you Address the Impostor Syndrome described in Lean In?


How would you address the impostor syndrome that women experience at times, as explained in Lean In? Do you battle against your own impostor syndrome?
Lean In used these examples: women often hold their hands up first before speaking when men holds the floor, and women tend to phrase questions when actually making an assertion.
Join the Discussion from AB Camp Online Tech Community hosted on MightyBell Platform, the same community platform for www.leanin.org

Thursday, September 12, 2013

Announcing ABCamp a Friendly Online Community for Beginners in Technology

Interested in web development, mobile, product, design, data analysis, any of the new hip technologies? This is a community that aims to support all people to fulfill their technology dreams. It is designed with women in mind, providing a community for those living far away from the epicenter of technologies, or those who cannot afford the time or money to attend meetups every day of the week.

Job and competition, recruiting opportunities will be available soon.

Join the community here: click here
Join the inner circle of developer's network here: click here

Below is the welcome letter: or click here
What is AB Camp?
This is an online community aims to help all in their tech dreams. If you are getting started with web development, mobile, product development, web design, and or data analysis, this is a community for you. It is designed with women in mind. The virtual community provides an easy-to-access resource hub for any one who has limited time and means to arrive and meet in person in San Francisco. There will be periodical in person events.
The community is free. Please adhere to law and online etiquettes to keep this a safe and friendly environment. We reserve the rights to delete and remove posts that have existed for too long a period, or have been reported to be offensive and attacking in nature by numerous members.
Online Activities:
  • Make a pledge today to start something new in technology: learn a new language, complete a new lesson, start a new chapter
  • Join a peer-discussion about any relevant topics, share useful information, resources
  • Read a featured editor's article / commentary about the current excitements in tech, read a tutorial, or getting started on a new technologly
Sustainability Model:
  • Get support from your peers by announcing your effort / goal
  • Get peer support and good wills by showing social proofs that you have completed the goal
  • Reply and engage in peer activities to show your support
  • Share and showcase your goal and accomplishments to stay on track, share on twitter instagram pinterest facebook
  • Hashtags : #ABCamp #aloftpledge
Member Benefits:
  • Women in Technology: get community support, peer and senior mentoring, building a habit of improvement, understand women specific concerns, first-hand access to women friendly environments, events
  • Career: Job opportunities (Coming Soon), mentoring and advising, community produced researching contents and reports, 1st hand access to publications (Coming Soon)
  • Web Development: opportunity to prepare for Hackathons, competitions as a team, get peer advice, tutorials, getting into a training schedule, cycle and sprints like in marathons

Thursday, September 5, 2013

Gender Hot Topics - Women in Tech Need to Leanin

May be 25+ emails and counting! A job posting for female junior developer internship position erupted a lengthy and pointy multi-way discussion in the San Francisco local Ruby meetup mailing list. How do we make sense of it?


  • A job posting was published as an email, female developers are encouraged to apply
  • The posting was mistaken as only encouraging women to apply
  • Several members lashed out on issues of equality, equal opportunity, discrimination, and sexism against men
  • Several members argue that the posting discriminates, if there is a "men only" posting, women would be upset too
  • A couple of members mentioned that most nurses are female but we don't that that men must be nurses, and they deny the fact that women are oppressed/discouraged/disadvantaged in the programming world. Citing only programming skills to be the criteria
  • Others point out the ignorance, the gender gap is clearly an issue, and the Brogramming, Men in Rails cultures are hurting female engineers' chances of entering the job field Updated 9/12/2013: please see our AB Camp community discussion on this thread, in wich I shared the resources that other members of the mailing list have pointed out as evidence of gender app in Technology in the Silicon Valley: click here to view on MightyBell. Mightbell is also the host of LeanIn Discussions.
  • Several members write that this thread and the negativity it has garnered is precisely what discourages women developers to advance in tech careers
  • Several members have to constantly remind others to stop attacking and "be nice"

This situation has been encountered by many female engineers and engineers-to-be. A gender difference and culture, job opportunity discussion quickly turn mean and pointy, discouraging. Even though these conversations are necessarily, but the quickly soured tone can hurt feelings of many women engineers and dishearten them to believe that the job field may be less equal than ever. One member suggested to take this discussion to a moderated civic format: a conference or event panel. It is a necessary important discussion that needs to be productive as well.

As I am designing a virtual meetup for women, I may soon face the same scrutiny from prospectives why the meetup is designed for women not yet open to all in the nearest future. I tried my very best to reply to this thread with my social scientist hat on: 

1. As Sheryl Sandberg has written in her Lean In master piece, women sometimes need more encouragement to apply because they feel like a "fraud" even when they are fully qualified. 

I wrote

Social scientists have confirmed again and again that equally qualified candidates facing a job posting the women are more like to think they are less qualified and not apply at all, even if they are fully qualified. In fact men are more likely to apply for job postings even if they don't meet the numeric requirements, such as years of experience. Encouragement is really needed in many scenarios

Then I wrote about the special needs of women in the current social expectation and responsibilities

There are special needs that need to be addressed : for example it is possible I argue that women face more danger when leaving a meetup late, and are potentially more sensitive to some jokes and remarks, and also may have some time and family restraints and social expectations - e.g raising a child while pursuing a coding career. Encouragement is special treatment? By definition. But we still need to address these needs and make the tech work place more open for women, and not just women. This work still needs to be done right?

I wanted to stay as objective as possible in my tone so that this message will be read and will not be sucked into the swirl of negativity. I call it my "suicidal" reply (indeed many other replies received constantly lash backs), yet it successfully made it to the mailing list without receiving a single argument. In fact, I received several private responses from women saying they are so glad that someone has said something without adding fuel to fire, but have stand up for the silent women. 


This was a trick that I learnt from Freakonomics, social scientists writing on topics that have mass attraction, writing about controversial topics with equal persuasiveness, generating discussions without victimizing. This will be the tone I adopt as I prepare for building the meetup for women. LeanIn talks about the same thing. For example, women are obviously paid less in many fields as data has shown, we need to fight back, but with the right method, or else the existing social expectation will also perceive women negatively (as Harvard business research has shown): more successful women are perceived as aggressive with a negative undertone, as opposed to successful men are perceived as ambitious and successful with a positive undertone.

The discussion goes on. I urge you all to Lean In with agility and wittiness.

React UI, UI UX, Reactstrap React Bootstrap

React UI MATERIAL  Install yarn add @material-ui/icons Reactstrap FORMS. Controlled Forms. Uncontrolled Forms.  Columns, grid