A community of students becoming developers, designers and better humans.

We blog our victories and our fears.

See some of our latest posts

How to Learn with CareerFoundry

I saw a lot of new students starting up the course today, so I thought being an alumi of the program , I'd give some friendly words of advice:

It's not about the answer.


Coming in, you dream about blazing through the course, a new found sense of glory after every little goal is accomplished. Eventually you just want to get through every assignment as fast as possible so you can say, "I did it! I completed the course! I'm a genius!"

I think maybe the best parts of the course, are when they drop the hand-holding a bit and give you your moment to shine. Or when you run into some unexpected problem (this will happen), and you have no idea what the problem even is, let alone an answer. These moments are not easy.  They are incredibly annoying. They're also a blessing. They help you learn problem solving, programming logic, and make full use of your brain. Savor these moments, especially in a low-pressure environment such as the course.


                         (My main CareerFoundry project, after redesigning it twice after the course had finished.)


In the same vein, use your mentor as a tool to learn about how things work, rather than just try to get the simple answer. In the long run, the answer doesn't really matter. It's the process of learning how to do it yourself that counts the most.

Currently, I'm working on a paid project that is immensely complex and I don't have much margin for error. I don't have a mentor to fall back on. It's scary stuff. I had a nightmare about it last night,... (A developer sternly told me, "I was an idiot and had no idea what I was doing." I woke up in a cold sweat.)
Seriously.

But luckily, I've worked very hard to LEARN the material backwards and forwards. I redid portions of the course when I had to, and I continued to make my own projects after the course ended. I befriended other hard-working students from the course and developers outside the course. I helped other students. I listened to podcasts about coding. I read books about coding. I still do all these things.

After all this experience, I know that I can find answers if I work at it hard enough. Even when I'm muddling around in languages and frameworks I don't fully understand yet. I may slam my fist in frustration, or yell to my plastered ceiling about "why Laravel is the stupidest framework in history,", and it may take many many hours,  but in the end I know I'll figure it out.


Trust in the Process

So when you're in the course, and after hours and hours find yourself inevitably thinking, "I JUST NEED THE ANSWER";   Think again. The answer doesn't help you in the long run.  But don't worry, you're not the first person to think that it will. I was there too. So was every other student in the Career Foundry program.

When you find yourself at that point where you are dying for that answer, thirsting for it with your very soul... take a break. Come back refreshed and ask yourself this instead:

 

"How can I use this problem to become a better developer?"






Build a Minimum Viable Product, and They Will Come…

…and then most of them will leave after spending 3.27 seconds on your landing page.

But don’t worry, this is the way things go in the start-up world…you don’t hit gold the first time. Instead, you “discover” your way there through trial-end-error based on how the visitors to your site respond to it.

To rephrase more fully: Build a minimum viable product, launch it sooner rather than later, find a way to get users who may be interested in the service or product you are offering to come to your site, measure their behavior while on the site, make adjustments to your site based on this behavior, get more users to visit…and repeat.

At this point you’re probably thinking “ok, that makes sense, but how does this work in the long-term and what is a ‘Minimum Viable Product’ anyway?!”. So let’s define our terms:

Minimum: The least you can get away with to accomplish your goal.

Viable: It’s not perfect, it’s far from perfect, but it works enough to demonstrate the core of your idea

Product: It’s not an alpha release. It’s not a beta release. It’s nowhere close to finished! But it is a product and despite the bugs and the issues in the UX, it’s ready for real use.

For short, we’ll just call this “MVP”. Let’s get into the “Whys?”

Why would I launch my product to users when it’s not finished and may have issues?

Because although it’s flawed, it’s a much, *much*, better use of time and resources than building what you think is a great product out to perfection, or even completion. Chances are great that you are going to fail the first time either way. In fact you will fail many times. It’s better to fail on a small scale, with minimum — there’s that word (!) — time and effort. The cost is minimal, and you learn a bit about what worked and what didn’t, and you take that knowledge and keep building and evolving your product with it.

How does this get me to where I want to be…with a solid product or site that offers tons of value and is in demand?

It gets you there in smaller steps, not giant leaps. So you will likely get there slower. But slower than what? Than if you spent 6 months or a year building the perfect product only to find out no one wants it? Because this is what happens 99.9% of the time with such an approach. It’d be great if you could just build to completion and launch a successful business, but this isn’t the reality. So it’s the “slower” way, but it’s also the “possible” way.

Won’t having a site or product that is flawed harm my reputation with users?

Most likely not. But it’s important that your users see weekly improvements and new features. They will understand that the site is evolving, and since you are listening to their feedback closely, they will feel invested and will *want* to help you make a killer product.

How do I actually implement this?

Since you are basically “iterating” the product on a regular basis, “agile development“, which I talked about in a prior post, is a perfect fit for the MVP approach. A typical process would be to identify a set of tasks to be implemented for the coming week, do the work, release, then “test”. The following week, repeat the process, taking into account user reactions to decide what to add, drop, or change.

Many small companies and start-ups find this sort of “small-chunking” approach to website and web application development the best way to efficiently user time and money while building a stellar product.


How to think like a poker player (or a programmer.)

At the Poker Table...


I'm playing the 2/5 Texas Hold'em game at the Venetian in Las Vegas. I haven't had many cards to play, and right after I decide to go home, I'm finally in a hand. A young 20 something male grabs 3 stacks of red chips and nonchalantly says "Three hundred dollars" after the final card is dealt. My action will complete the hand. The options are "Do I fold, or do I call?" If I call and win, I'm will win the last $300 plus the $200 that's already in the pot. If I call and lose, I just wasted an extra $300.  Folding is the safe play here... but something doesn't seem right.

This is why poker has been said to be "hours of boredom, and moments of sheer terror."



My hand is very weak. But that's only half the story. What's important is what cards this may player hold. I look at the player. He looks right into my eyes with a veiled threat. I think about how the whole hand played out, the entire process. I combine all the variables and decide to say those dreaded words, "I call."

Coding Logically


Thinking logically through each step, is something both programmers and pro poker players have to do. In poker it's important to be able to see through your opponent's eyes and add together all of the different variables. "Why did he bet this specific amount here, why did he stare into my eyes, what cards does he think I have, why did he stop chewing his gum when I asked him a question"... The list can go on a long time.

For programmers, while it's not exactly the same, it's very similar. Here's a rather simple, but fun, problem I had to figure out on The Error Logs:

"How do I make images that are published by a blog user shrink to fit the screen?"


All this logical thinking resulted in this:




The funny part is I can't even remember why I have that line "typeof images[x] !== "undefined".... Which is bad lack of commenting on my part. Live and learn. I'm sure it's serving a purpose so I'm not going to touch it. ;)


Beyond Code... Beyond Poker


Personally, I've found this process of going through each step logically to be life-changing. As I did it more and more (it first started with poker 11 years ago), I found it began to trickle down into other areas of my life. It's easier for me to take a dispassionate view of things going on around me, allowing me to make better decisions. I'm no Spock just yet but my world view has changed because of it.

A pretty cool thing to happen from just playing poker and coding.

As for that Hand

I won. My opponent threw his cards in disgust at the table, emoting loudly about how stupid a call that was.

He wasn't thinking logically.



My Post was changed by the admin ;)

The NY Red Bulls are the BEST Team EVER.

Well, besides the loaded LA Galaxy of course.