Geeklist Update

A meetup wrap-up on our Firebase event with @anantn

Tue, 21 May 2013 06:27:33 -0400

Apologies for the tardiness of this writeup of our last SF Meetup. In summary, super informative and useful. We had Anant Narayanan of Firebase giving a presentation to over 60+ on how his team had built a real-time, highly-available Back-End-as-a-Service. (Slides are up here).

Rather than try to do justice to the talk, I’ll give you bulleted the 10 Lessons Anant discussed in his talk. FWIW - Anant knows real-time as he was the guy who wrote the WebRTC specification that is now accepted and is spawning loads of new services. So here are Anant’s 10 Lessons Learned. You’ll have to go to the deck to get the full effect - or catch him at another meetup.

1. Data Synchronization > Message Passing

2. Event-driven APIs are not Ubiquitous (Yet)

3. De-normalization isn’t Intuitive (Yet)

4. Realtime isn’t Easy

5. The Browser World is Ugly

6. Immutability is King

7. Latency Compensation is Important

8. Virtualization Doesn’t Always Work

9. Client Complexity Helps Scalability

10. Declarative Security Works Pretty Well

We wanted to thank the folks at the invite only RunwaySF startup co-working space for lending us the space in the new Twitter Building (If you’re a startup and awesome then email us at info@geekli.st and we’ll intro you in) and a special thanks to Geeekli.st sponsors NewRelic and Smart Bear Software. Our next talk will bring the Mashape crew in to talk APIs. The talk will be titled “Making APIs Developers Love: Tips and Tricks”. Thanks and see you there!

Integrating with LinkedIn - Geeklist dives deep into data, collaboration and sharing

Thu, 16 May 2013 05:03:04 -0400

Today Geeklist released a deep dive integration with LinkedIn. Being able to log in using LinkedIn is basic and just pulling data is boring. So just like with our Facebook Open Graph integration, now many of your activities on Geeklist will auto-magically appear in your LinkedIn activity stream whenever you want it to. Just go to your settings and link the account:

This means when you give someone a ^5 your friends in LinkedIn will be able to like that and even join you on Geeklist.

If you announce something in the Geeklist activity stream, for example a statement in a micro, you may just get a LinkedIn team member to like it! (Thanks Nash! We know you’re a huge Geeklist fan and your achievements are bad ass!)

You can invite or connect with your friends from Linkedin on Geeklist, even view a LinkedIn snapshot of your peers background while holding a convo with them!

Yes, you can swap between the Geeklist profile data or the LinkedIn data just by selecting the icon next to ‘view more info’. Expect these convo pages to become much more interactive, with increased data, analysis, conversation capabilities and collaboration. If you’re following a friend and they follow you the convo tool is free and open, just like Twitter DM or Facebook PM. They are also real-time so you can see when the other person is typing. if you’re a company that is hiring or looking for bigger collaboration and connection you can upgrade and invite anyone to join you in a convo. (Contact us at info@geekli.st for more info on company hiring or promotion accounts)

As Geeklist is about giving credit where credit due… Great team work Bruno, Jose Luis, Eriks and of course Sam! Expect many more new and engaging releases from the rapidly growing Geeklist dev ops team!

Oh and don’t forget to visit our company sponsors: SmartBear - They have Free Load Testing Software for your web app or API’s.

Thanks! The Geeklist Dev Ops team…

A meetup wrap-up on the Geeklist node.js talk by @dshaw

Thu, 04 Apr 2013 04:08:00 -0400

On April Fool’s Day, a happy crowd of Geekli.st members (and friends) gathered for pizza and beer to listen to a lecture from an angry pink unicorn. That would be Daniel Shaw (@dshaw), a Voxer engineer, Node.js expert, and one of the principals in the leading Node.js consultancy, The Node Firm (@thenodefirm). His topic? Running Node.js in production. It was a nice show, with light slide-fare and loads of hard-won advice on how to plan, deploy, and scale big, big applications running on Node.js.

Most of the crowd stayed through the whole show. Daniel gave a great talk and hung out for beers afterwards. All in all, a good time with swag that disappeared in the first 5 minutes.

As the Geekli.st SF Ambassador, I was very stoked with the evening, which saw over 60 attendees out of a RSVP list of over 90. Why? Well, talk about burying the lede - this was the FIRST SFGEEKLI.ST MEETUP! We plan to do many more and possibly add an additional monthly event down in the South Bay. While virtual communities are awesome, putting flesh to face and code is something we hope to do a lot more of at Geekli.st. But rather than do things in the traditional Meetup vein, we definitely want to ensure that our events have an educational flavor and stick to topics that we think our members will find not only interesting but useful for their day jobs or their side projects. (So we may stop calling them Meetups and stay tuned for the rechristening).

But I digress. The bottom line - thank you for all those who turned out. Thanks to Daniel for doing yeoman’s work. Thanks to Geekli.st founder and CEO Reuben Katz (and new CTO Sam Estrin) for buying us all pizza and beer. And thanks to the stealthy Runway co-work space in the Twitter building, for hosting us. May this be the first of many. Feel free to joint our Geeklist Meetup group and lay suggestions for future events on us, either via email, on Geekli.st, or at the Meetup page. See you soon! - Alex Salkever - Geeklist Ambassador to San Francisco

The Other Reason Companies Build Freemium Software

Tue, 02 Apr 2013 12:47:16 -0400

[This guest post for Geeklist comes from Lorinda Brandon, Editor and Strategist at SmartBear Software. You can follow her on Twitter or find her blogging regularly at SmartBear.]

It’s no secret that many companies develop a line of freemium products in an effort to drive revenue. But what may not be apparent to most are all the other reasons companies develop freemium products. It certainly wasn’t apparent to me until recently. Sure, I’ve used my fair share of freeware (and, in the process, learned when I could do without the premium features and when it was time to pay up), but I have rarely had the opportunity to be in the strategy discussions about those products.

The reality is that freeware (and its conjoined twin, freemium) is not new. Even back in 2008, Wired.com wrote about how the lower costs of building and managing software products allowed companies to offer a free tier to bring in greater market share. As Chris Anderson points out, “zero is one market and any other price is another.” While the industry tinkered with how to leverage a free market into paying customers, some of the most popular names in the biz were making their mark with free offerings – and, in essence, changing the accepted software business model dramatically. In one of the best articles on the subject, TechCrunch discusses how some of these companies have learned to tie their freemium offerings back into sales, driven in large part by grass-roots growth within the enterprise that then translates to enterprise licensing.

Starting with a freemium product means that the user gets to decide when/if the product is worth paying for. Unlike a free trial, it is more than just a taste test – you can invest significant time and data into a freemium product without ever paying for the premium features. I, myself, extoll the virtues of Evernote often and everywhere and I run it on every device I own (one of the reasons I love it so). I have a lot of data stored in there, some of which I consider to be critical. But I have yet to pay them a dime.

But as more free tools hit the market and more open source technologies are offered to developers, the cost of building software is so much lower than ever before that many companies can afford to have a broad fanbase comprised of free users. They just need to do the math to determine how far to take that model before they go bankrupt on freeloaders.

All this business talk would make you think that having a freemium strategy is just a money-making device and that the only reason companies adopt this strategy is to profit from it. That’s what I thought too. Until recently, that is. I’ve been privy to boardroom discussions in recent months about why we should build free software and it was refreshing to find that, while some of the discussions did include spreadsheets and number crunching, an equal number of discussions didn’t. Those other discussions were about things that resonated with me as a technologist:

Obligation to the industry. For those of us making money, we owe the new young entrepreneurs a leg-up. Most of us have worked at one point or another in a start-up where money did not flow freely, if it even flowed at all. The more we help those companies out with free tools, the more successful companies we bring into our economy. According to a 2011 study by p2pfoundation.net, “FLOSS [Free/Libre/Open Source Software] potentially saves industry over 36% in software R&D investment that can result in increased profits or be more usefully spent in further innovation.”
Encouraging innovation. Innovation requires some degree of freedom: freedom to think, to play, to experiment. There is no question that having freemium products to invent with allows developers to find what works for them and get their ideas brought to life more quickly. The more we offer free development, testing, and monitoring tools, the more we benefit from the creative thinkers outside the enterprise.
Making better software. It’s not just that more developers will be able to build better software because they will have a variety of tools to choose from; it’s also that we (the suppliers of freemium tools) will be able to tap into a broader user base for feedback about our products and features so we ourselves can make a better product.

A part of me will probably always look at free offerings with “TANSAAFL” whispering in my ear, but I also know now that there is another, less cynical viewpoint. So, here’s to freemium – may it be the fuel for many creative fires out there.

6 Things Your Company Can Do To Stop Turning Off Candidates

Fri, 29 Mar 2013 12:03:00 -0400

[A guest blog post for Geeklist by Gayle Laakmann McDowell. Gayle is the founder / CEO of CareerCup, and the author of Cracking the Coding Interview (Amazon.com’s #1 best-selling interview book) and The Google Resume. Gayle has worked a software engineer for Microsoft, Apple and Google, and served on Google’s hiring committee. You can follow her on Twitter, Facebook, Quora, or her blog.]

I talk everyday to candidates who are confused, overwhelmed, and frustrated by the technical interview process. I won’t lie; some of this is the candidate’s fault. They should be prepared and a lot of their questions could be answered from their recruiters (or from their friends).

That said, recruiters and companies can do a lot more help their candidates than they do. What’s in it for them? Better prepared candidates. Happier candidates. Candidates who will refer their friends. Less work on the recruiter’s end answering silly questions. All of this means one thing ultimately: the company will have an easier time hiring. Isn’t this what you want?

Here are six ways you can improve the process for your candidates, and in turn for yourself.

#1 Tell Candidates What Types of Questions Will Be Asked

Many candidates have no idea what to expect in an interview (especially technical interviews), so they waste their time in preparing unnecessary topics. The better prepared the candidate is, the better you can assess them. If you’re going to be asking technical questions, tell them – and tell them what sorts of topics will be involved.

Even better – give them some direction on how they can prepare.

#2 Explain How They Will Be Evaluated

For technical roles, many candidates think that they will be evaluated on some absolute basis or that they think they must get every question correct. Then, when they make some mistakes in the interview, they panic and think they’ve suddenly failed.

Tell the candidates that perfection isn’t required for an offer, and that their performance will be judged relative to other candidates on the same question. Let the candidates know that even the best candidates make mistakes, in part because technical question are supposed to push them to think.

Do you really want candidates panicking because they made a single mistake? This doesn’t help anyone.

#3 Tell Candidates When They’ll Hear From You (And Do It!)

Don’t leave candidates hanging. Before going in for an interview, the candidate should know the recruiting timeline. When will they hear back from you? Who do they contact if they haven’t gotten a response? Ideally, give your candidates at least two contacts they can follow-up with.

Many candidates, for some reason, think that if a company doesn’t respond to them within X days, then it’s means a rejection. (“My friend heard back from this company next day, and it’s been three days for me. I guess I’m rejected.”) Yes, I know that’s not true, and you know that’s not true, but the candidate doesn’t. So tell them.

#4 Give Feedback

If you’re doing first three things (and are you? Are you really?), here’s one you’re probably not doing: giving candidates feedback. Rejecting them? Tell them why. What did they struggle with? This is an excellent way to set yourself apart as a company. Candidates will appreciate this and be better prepared if they re-interview in another year – and they may even tell their friends to apply to you.

And, if you do this between phone screens and onsite interviews, you’ll wind up with better prepared candidates. All the better for you!

#5 Tell Them and How They Can Reapply

Just because you reject a candidate once doesn’t mean you’ll never want to hire them. Maybe they had a bad day. Maybe they were just too inexperienced. Maybe your interviewers made a bad call. Who knows? A not-ideal candidate could easily turn into a great one within a year or so.

If you reject a candidate (or if they decline your offer), let them know when and how they can reapply. How long do they have to wait? In what cases might you consider them earlier than this? Do they re-apply online, or do they reach out to their recruiter? What happens if their recruiter has left the company by then?

Let the candidate know the answers to all of these questions. More clarity here = more candidates.

#6 Ask the Candidate for Feedback

What else are you struggling with? Are some of your interviewers turning off candidates? (Let’s be honest: if you have developers doing interviews, they may not all be the most, uh, “social” bunch. That dev lead of yours might be a “really nice guy once you get to know him,” but he might also be coming off negatively in an interview. You need to know this information.)

You’ll never know what is going wrong until you ask. Give your candidates a way to provide (anonymous and non-anonymous) feedback on your interview process and on their interviewers.

When you improve your recruiting process for candidates, you improve your ability to get the right candidates. No one – not even the hottest companies – can afford to be turning off candidates.

The best part? It’s really easy to do this. Create a document – I’ve helped companies do this in the past (please contact me if interested) – that you send to all your candidates about how to prepare, what to expect, and answers to other common questions. This is perhaps the best bang-for-your-buck change you can make to your interview process.

- Gayle Laakmann McDowell

I Can Haz Telco: The Ins and Outs of Partnering with a Goliath

Mon, 25 Mar 2013 16:46:00 -0400

A guest blog for Geeklist post by Alex Salkever

So you have the latest whiz-bang smartphone app. You got mad coding skills. You have a monetization strategy that would slay Larry and Sergey. Naturally, you want to partner with a large telco to maximize your distribution and get some do-ray-mi flowing to your coding teams and get that VC monkey off your back. Right? Or at least do a throw-down press release to solidify your B-round. Ummmmm.

Playing the telco game is tricky for a small company. As someone who works inside one of the world’s largest telcos, I have watched a number of startups travel down the partnership path with various degrees of success. Here’s a quick guide to playing that game without getting crushed, drowned, or fried. Telcos are not inherently evil. To the contrary, they actually want to build things their customers use and love. But they view the world very differently than you do. To that end….

1) Map That Org - If you have decided you want to get into the game, you need to understand the decision makers. This is common for many large companies but is a bit more complex with telcos. First line of defense is usually biz dev or partnership team. Next will come a product team. Then will come a technical due diligence team. Then comes the executive sign-off. And last, oddly, will come the guys that actually could make you money - the sales and marketing teams. You will have to train them up to sell your product, or at least to give you decent distribution and marketing push. All boxes must be checked to get to a final deal. If you don’t know which box is which, or who owns what box, you could talk in circles for years without getting anything done. Equally important is to get an inkling of potential competitors that have talked to these folks and where alliances may lie. You can have the hottest product in the world but if the unit you are talking to feels most comfortable with an inferior product from a large company, then you have to sell around that obstacle. And if you don’t know it exists, you are selling blind. So map that org and learn who the players are as well as their relationships and preferences.

2) Speak Their Language - Mobile startups (and let’s be honest, in telco land we are mostly talking mobile startups) love to come and talk to me about MAU. Now, I know what MAU means. But most of the folks inside my org do not speak MAU. They understand ARPU. Anything that can jack ARPU is inherently GOOD. This hints at what is a major problem in speaking to telcos. If you talk like to a telco the same way you talk to a venture capitalist, you will have serious problems communicating both your value proposition and core aspects of your monetization strategy. My advice? At first, speak plainly. Do not try to use industry jargon or metrics terms. Learn the telco language and then apply it to your business in a coherent way to explain what you do. When in Rome…

3) Be Patient - For a large business unit inside a major telco, two new product launches a year is a normal amount. Sure, app stores are different. But, in general, the process moves far more slowly than may be comfortable for most startups. This Is Normal. Telcos move slowly because they are designed to be careful and not break things. If your game app goes down, nobody dies. If something a telco has added to its ecosystem causes problems and brings down infrastructure, probably no one dies but they may - and other really bad things can happen, like bank ATM networks going dark (witness the recent madness in South Korea). So to get to a firm agreement, you should expect to spend more than a year, in most cases. Three is actually not unusual. Be patient, grasshopper. It’s not you. It’s them and it’s the way they are built to operate. - safety first.

4) Always Maintain a Plan B - Large telcos are political organizations, like any other large org. While getting a new project or product approved can run years, killing that project or product can happen much more quickly. For a startup, absorbing such a catastrophe can be difficult, particularly when you have built your monetization, distribution, or funding strategy around that Big Shiny Telco deal. For the telco, too, deciding not to pursue a deal with a smaller company is just part of doing business. They mean you no harm but that’s the way the game is played in the Big Leagues.

5) Plan for the Firehose - I don’t mean the huge rush of customers. Rather, I am talking about the implementation and negotiation phase. Every process you touch will likely require a lot more time and effort than doing a deal with a small, nimble partner company. Lawyers get seriously busy with big docs. Technology teams rip your product down to the studs. Business Development and sales teams will hit you up hard for potential revenue numbers so they can update their business cases and revenue forecasts. You’re not in startup Kansas anymore. In the big city, process is critical. If you can’t handle the process, think twice about entering the deal.

If you are thinking of snuggling up to a major telco and follow these guidelines, you will increase your chances of success significantly and minimize brain damage and frustrations. So think big, code fast and stay thirsty.

How to rebuild a tech team while drinking your own punch

Tue, 19 Mar 2013 04:32:34 -0400

Imagine you’re a startup co-founder. You are running a killer stack in node.js on the front and back-end with Mongoose, Redis, Hadoop, jQuery, Express, and your team is running so fast they test on their local machines and push straight to production. You’re migrating from Heroku to Joyent and you’re split between the two, new releases are pushing out weekly and the site is screaming. Then it happens. Investors freeze pre-christmas and 2012 is coming to a screeching halt, so the core team finds side work…which becomes full-time work. No problem, your co-founder is a bad-ass coding cowboy with a golden hat, but wait… he’s found a passion, a big passion and opportunity for something he just can’t pass up and it’s not your company. So as a lifelong friend who believes in doing what you love, you tell him the only rational thing you can say: “it’s ok do what you love… I got this”. But wait. The last time you had to code anything was in 1999, meaning having to find and hire an entire tech team from the ground up…immediately.

This is my story over the past 3 months. It’s not a sob story. On the contrary, it’s a story of excitement, passion and personal growth. I saw it as a huge opportunity to utilize the system we built in Geeklist and become my own case study. Here’s what I did.

Step one was to identify all of the skills needed to keep the site running smooth so that no user ever felt the changes.

I needed a stable front end engineers, a solid back end hacker and some full-stack node.js rock-stars sprinkled on top. Easy enough, right? Well if you’re in tech and you’re hiring anyone you know it’s hard. If you’re hiring on the node.js stack the qualified candidates dwindle even more… or do they? I immediately posted this job post on Geeklist:

In less than a day I had over 30 replies by amazing engineers from around the world. What amazed me most was that most of them have been Geeklist users for over a year and some were even our very own ambassadors. Right under our nose.

Step two was to consider the value beyond financial for developers to want to work with Geeklist. Even though we did have a few new investors and revenues began to kick in, It wasn’t not enough to pay for everything or everyone we needed. There had to be another incentive.

Here is where building in a new technology helps. Turns out It wasn’t cash incentives most of the applicants expected. They wanted the chance to contribute to Geeklist, to improve their skills in node.js, gain some street cred and be a part of an amazing and international team.

This is where the personal growth came in. I learned in under two weeks the value of a strong brand. I learned just how much our users believe in Geeklist as a global community. There has been much written about Founders stress, anxiety and the damage being a founding ceo can have on a person…it can take a toll. This is a story of the opposite. I’ve never felt more joy in my career than when people I have never met before offer to help for some options and the opportunity to work together with me and Geeklist. It’s a great feeling and one that makes being a founder awesome.

Step three was to get down to business… armed with Geeklist Convos, and a bunch of amazing engineers wanting to help, I set out to talk to as many as possible. I met with some in SF and many via skype. One by one they offered to help, to take on pieces of the project and to become part of the team. Then Sam called me out of the blue. He wanted to take on the challenge of becoming the Geeklist CTO. The best part? I met him on Geeklist about a year ago when he added this impressive card and I reached out to grab coffee. (Those of you who think grabbing coffee/tea with someone new is a waste of time are dead wrong.)

Step four is to pull the trigger on every one with the passion, skills and availability. Immediately. Don’t wait. Give them a chance and a challenge and watch them deliver!

Lessons learned?

Your best resources are within your own network, the trick is to surface them. Geeklist did this for me, not because it’s my network, but because it surfaced up my network. That can work for anyone.
Don’t worry about your budget constraints if you believe in your brand. Find others who are passionate about your product and reach out to them. You may be surprised at how far your core believers are willing to go for your startup or cause.
Don’t be afraid to go outside of your region or even country to find people passionate about your product. There are no boundaries or borders in the interwebs. When it comes to great coders, they are everywhere around the world and excited to help. Hire based on passion and skill, not location.
If you see someone interesting on Geeklist. Invite them for coffee, a skype chat or a Convo inside Geeklist. You never know what that may become in the future.
Passion, achievements and an active profile is more important than resumes, answers to questions, challenges, tests or raw data scrubbed from every possible source on the web. If you want a team that pours love into your product, hire based on their love of your product more than anything else.

Meet the New Geeklist Family. Found and contacted using only Geeklist. We will be adding more passionate and talented members all month long, until every task in Asana has an awesome developer willing to help us complete it. We are drinking our own punch and it tastes pretty darn good. If you’d like to try it too just contact us at info@geekli.st - Reuben Katz, Co-founder and CEO of Geeklist - grateful to have a passionate community.

How Geeklist went guerilla last year @sxsw with @scobleizer, peanut butter, and whiskey #sxsw

Tue, 05 Mar 2013 21:55:41 -0500

You don’t need a venue… crash one. You don’t need a caterer or big staff… invite friends over, make something simple, get a cooler from the walmart (take a cab to one) What the heck, it’s SXSW and really anything goes. Have fun because unless you have a huge budget and team to help you’re not going to get anywhere with smaller events. So go rogue! If you’re looking for a great, last minute, cheap and fun promo… crash the Hilton lobby (or similar) with a well known industry giant at Midnight and give out something delicious to drunk SXSW’ers.

So. Last year we partnered up with Robert Scoble (@scobleizer) for a quick and exciting party-crashing style event. We were joined last minute by Jon Gottfried @jonmarkgo and some other Twilio friends and made a party out of it. Why? What better way for a startup to make an impression than by meeting these big names after the party when they are hungry (and perhaps a little tipsy) with a snack and beta invites!

The DrunkenPBJam is the brainchild of Robert Scoble of Rackspace and Reuben Katz of Geeklist and together we made it happen!

What we decided to do was ambush the Hilton Lobby guerrilla style (since they wouldn’t give us permission) with a cooler filled with peanut butter and jelly sandwiches topped with Geeklist beta invites and a sticker or two.

So to make the most of it we started tweeting about it a few days in advance (You seriously do still have time) set up Plancast and Meetup.com and posted it on Google +.
We set up a Twitter account for DrunkenPBJ and tweeted a few days in advance about our plans, when and where and continued to update our followers.

Making the 200+ PB&J’s and emptying a Jack Daniels bottle with @jonmarkgo of @twilio

Many a Smucker’s jar was emptied.

After arriving at the Hilton Lobby we were greeted by a flurry of hungry people that had come to grab a sandwich and a beta invite and let us know what a great idea this was.

Passing out sandwiches in the Hilton Lobby

After about 10 minutes and giving away half of our sandwiches (around 100+), the Hilton security guards caught on and very kindly escorted us out. We made our way to the corner and after about 20 minutes we stealth-fully made it back up to the entrance where we managed to give out every last sandwich.

The security guard escorting us out

Robert Scoble led the way out of the Hilton Lobby with people following and grabbing sandwiches

Walking out in a blaze of glory with our Geeklist sticker covered cooler on wheels, full of Peanut Butter and Jelly sandwiches…only to return to the scene outside to give them out to hundreds awaiting cabs!

Overall our DrunkenPBJam was a success and hilariously fun! We met a few sober people, a lot of confused people and a whole lot of drunk people but they were all amazing people! Many of whom we’ve stayed in close touch with and done business with later. To top it off, the event was joined by some real industry greats like Wayne Sutton, Liza Sperling and Susan Beebe.

This year if you’d like to run your own we’d be happy to help, but we won’t be attending SXSW. So this year if you want to run your own I’m sure you’ll get plenty of love, tweets and smiling new users!

Best of luck at SXSW!

Geeklist CTO & Co-founder steps down and new CTO joins the cause

Thu, 28 Feb 2013 23:42:46 -0500

After two amazing years working relentlessly together building Geeklist, our Co-founder and CTO, Christian Sanz, has decided to step down to pursue some truly amazing new passions and opportunities. He remains a significant shareholder and close advisor to Geeklist, spreading the Geeklist love around the tech community as he continues to innovate the world around us and, as for the past 10 years, he and I remain the closest of friends.

While this is a big change, we are extremely excited to announce Sam Estrin as the new CTO of Geeklist. Sam is a friend, advisor and avid Geeklist user. In fact he and I met on Geeklist right after he joined nearly a year ago, proving that in fact the best talent in the tech world is found right here in Geeklist.

Here is a little about Sam’s background:

My name is Sam Estrin and I began my career, at the age of fifteen, as one of five founders of MotherNature.com. As the original CTO of MotherNature.com, I developed the first version of MotherNature.com and was responsible for managing the supporting infrastructure. Billed as the world’s largest online vitamin, supplement and mineral supplier, MotherNature.com was taken public by Bear Stearns, Whit Capital and Hembrect and Quest in 1999 and reached a peak market cap of $600M.

At nineteen, I co-founded MediaWebcast. A publicly traded “trans-media” company, MediaWebcast, created four cable TV shows and garnered revenue through cable broadcasting, streaming video, VHS/DVD and intl. content distribution. As CTO, I directed the creation and management of all TV show websites, maintained infrastructure and created complimentary software products. Software products like MediaLimiter, an application developed to combat online video copyright infringement. MediaWebcast reached a peak market cap of $70M.

At twenty-one, I founded Odin Metatech, Inc., a firm that produced unique technology solutions including Odin Organic Framework and Odin Assemble. Odin Metatech rapidly expanded to provide complimentary consulting services including SEO/SEM, compliance and security. , At twenty-eight, I began working with TASER International. As CTO, I led key development activities within the Evidence.com division, which created the Evidence.com SaaS product. My responsibilities included architectural planning, developing security policies, managing both the UX team and Solr search team, authoring the Evidence Transfer Manager software, managing transcoding services and virtualized development environments. TASER Intl. trades under TASR with a market cap of $273M.

I am now CTO of geekli.st …

But that’s not all. We are also proudly announcing the addition of Ed Palumbo as Director of Business Development. Ed joined Geeklist as a user in September of 2011, a mere two months after we launched, and is in our first 500 Geeklist users! A true core user and passionate Geek, Ed comes to us from Opera Software where he built community, monetized, and managed projects in business development. Ed considers himself an ‘amateur epidemiologist,’ consumed by growth concepts, great data, and predicting cultural trends. He studies game theory and how people will continue to augment their lives with technology. Oh, and he loves LEGO minifigures.

We are in a rapid growth phase, with growing revenues, a growing user base and growing our tech team, international ambassadors program and biz dev operations around the world. Thank you Sam and Ed for joining the Geeklist team. Thank you Christian for trusting in me to carry on our dream! ^5 - Reuben Katz CEO and Co-founder. Geeklist.

Wanna Self-Publish a Tech Book? Here's What You Need to Know.

Thu, 28 Feb 2013 03:10:00 -0500

[A guest blog post for Geeklist by @volkan]

A week ago, a reader in China bought the 300th copy of JavaScript Interview Questions. In retrospect, that’s pretty good for a work-in-progress technical book with virtually zero marketing budget. The book is not even finished yet. By the time of this writing it has 46,033 words and298 pages, and there are still empty pages, incomplete sections, and drafts in it. I will come to that soon, but first let’s agree on the definition: “Self-publish” means that I did not have a publisher that helped me when writing JavaScript Interview Questions.

The book is not even finished yet. By the time of this writing it has 46,033 words and298 pages, and there are still empty pages, incomplete sections, and drafts in it. I will come to that soon, but first let’s agree on the definition: “Self-publish” means that I did not have a publisher that helped me when writing JavaScript Interview Questions.

But if I do not have a publisher…

How do I manage the overall process?
How do I communicate with the readers?
How do I distribute the copies?
How do I market my material?
How do I get it reviewed?
What tools do I use to actually author the book?

Those are some of the many questions that I receive regularly. In this post, I will try to clarify them, share my story and describe the types of challenges that I faced along the way. If you have any other questions just send me a convo, I will try to answer them all, and update this post accordingly.

Before we begin though, I want to clarify the most common misconception:
You don’t write a book to be famous.

Self-Publishing a Book Is not for the Fame

No matter how perfect, authentic, and unique it is; your book will not stand out. – Stephanie Meyer’s will. Yours won’t. Get over it.

Why? Because the odds are already against you. An average ebook on amazon will sell around 100 to 150 copies. Coincidentally enough, that’s the number of your of your friends, colleagues, relatives, and family combined, known as the Dunbar’s number.

So the hard truth is no one cares about your book. Your friends will seem interested, so that they can get free copies of your hard work, maybe.

Welcome… to the real world.

That’s why self-publishing a book is just like leading a startup (more on that below): In either case, the odds are brutally against you.

So Why Even Bother Writing at All?

So if it’s not fame, nor money? Then why write a book?

Well… everyone has their own reasons for this.

One of my reasons is the instant satisfaction I get when I share knowledge. If you are a blogger, you know what I mean: It doesn’t matter whether you have a single reader, or a million readers. You will have an ongoing thirst to write and share more.

Another reason is the incurable curiosity of mine:

I’m a geek, and I’m proud of it. In every aspect of my life, I want to dive deeper, and learn more. I urge to have a deep and solid understanding of a concept, before talking about it.

All these years what I’ve found is that simply doing extensive research and reading a lot on a subject matter is not enough to fully grok a concept. And I feel like the best way to learn something goes through actually teaching it.

Why? Because knowing that people will read your arguments pushes you to do more fact-findings, to be more rigorous, and to fully understand the idea you’re about to present. It switches your mind from being a consumer/memorizer to being athinker/analyzer.

Ever been to a code review? Then you’ll see what I mean.

I’ve realized that I learn a lot while I write. I would not have gained half of that knowledge if I were passively doing research.

Why Self-Publish?

Okay; there are reasons for someone to write a book. But why suffer all the pain to do everything yourself by self-publishing, rather than talking to a publisher and letting them do most of the legwork, so that you can focus solely on your writing?

The answer to this is simpler than the one above:

Self-publishing gives you more control over the content and design of the book.

You don’t want to fight to convince your publisher about why you present a chapter the way it is. You don’t have to convince them why the use of a technical term should be exactly the way you intended to be. And moreover, you don’t have to deal with a teenage intern, sending you editorial changes that you completely disagree with.

You have total control over your own content.

This freedom gives you great power. And as always, power is not without side effects.

Before coming to that, I want to share how my ebook adventure began, if you bear with me.

How It All Began

Due to reasons that are out of my control (startup bankruptcies, corporate strategy changes, layoffs, and so on) in the last couple of years I have been to at least a hundred technical interviews on JavaScript Engineering,Front-End Development, and related positions.

So it started with a layoff, and then I found myself preparing for the upcoming job interviews like crazy.

To prepare for those interviews, I had read a dozen of “technical programming interviews” books. That’s almost all of the candidates on the job market do, anyway.

And at a point of epiphany, two things smacked me right on the forehead:

First and foremost what was written in most of those technical interview books were either ill advice, or extremely open to misinterpretation, or werwedownright wrong in so many levels.
Secondly, although JavaScript was the most widely-adopted language in the known universe, and it was a skill that’s widely sought for, there was not a single technical interview book on JavaScript at all.

Let’s take a typical interview question, which almost all of those books have:

How do you balance a binary search tree?

… bah humbug!

To be honest, why on earth would I need to balance a BST? Even if I do need to balance one, I will google it. And I will not use a whiteboard to devise my algorithm. Whiteboards are extremely inefficient for compiling, debugging, and running code. If you ask me why I would use a binary search tree though, then we’re on to something.

Can you see how a virtual reality the interviewing setup is? Every step of the process is specially crafted to keep you out of the game.

Jokes aside, if acing your dream job was as easy as memorizing a set of questions and parroting them to the interviewer, then everybody would have done it.

Nobody Had a Clue

The sad thing I realized was, without having a single clue of what to do, candidates were constantly doing the wrong things, while expecting a positive outcome.

In deterministic systems, when you feed the system the same input, you always get the same output. Interviews, no matter how well-designed they are, are far from being deterministic.

And don’t get me started about the feedback mechanism. The only feedback you will get out of the process will generally be a “we will call you back later”. And either you get an offer, or they never call you back. In the latter case, you will never have any clue of what went wrong at all.

In the Land of the Blind…

It was that moment, when I realized almost everyone was doing it wrong:

Interviews were not something that one would be prepared overnight by memorizing a book. Moreover, it was not about the questions; it was all about the process.

You are not preparing for your CS101 final exam, you are getting ready to make a career shift. And memorizing questions is neither the correct, nor the most intelligent way of doing it.

In conjunction with all these, it suddenly appeared to me that most of the interview books were nothing but a to-be-memorized pile of definitions, Q&A, and brain teasers, along with lots of ill-advised suggestions on sensitive topics including “salary negotiations”, “how to deflect a question by asking a counter question”, “how to manipulate the interviewer to take control of the overall process” (hint: youcannot, and you should not), and the like.

Rather than giving the readers some HR Manager’s perspective on what interviews should look like, I aimed to hand over them the red pill and tell them what the JavaScript Engineering interviews really are, and what they will need to know to get the job they want.

With a belief that can I disrupt the status quo, and make a change, I rolled up my sleeves to write a book that teaches how to think.

Instead of forcing the reader memorize a set of rusted questions; I would be showing the most important parts of JavaScript and how they fit together in an interviewing context.

Long story short, I had a strong motivation to write the book. The next thing was to gather as much data as I could.

Collecting Materials

After having decided to write the book, the next thing was to gather resources.

Luckily, I was taking notes after every interview I attended to (an advice I took from one of my mentors, which worked out really well). I generally did it even before leaving the building, while my mind was still fresh.

I used those notes as an initial framework for the book. These notes were not only about the questions being asked, but were also about:

What I did,
Whether I have any moments of embarrassment,
What I woul have done better, if given a second chance,
What were my weaknesses, what were my strengths,
How I expressed myself, how I should have expressed myself,
If I were passionate enough, how I felt,
Whether I believed that I was a match, if not, why? … and so on.

I noted down all the technical interview questions, too. Then I changed some of the technical questions to be put in the book due to NDA requirements, while trying to maintain the same difficulty and tone.

I also conducted an extensive research on the topics that I had been asked in the interviews.

After two months of initial preparation, I came up with a bibliography of more than 200 articles, tutorials, and websites, along with hundreds of draft manuscripts.

Then I organized all my references into logical pieces: chapters, sections, and subsections, resulting in a semi-organized knowledge, enough to write a series of books.

After having all the resources bundled together, the next thing was to seek a tool set to merge them into one coherent book; find a way to communicate with the audience of the book, figure out how to do sales and marketing, which I want to call as “My Setup” as a whole.

My Setup

For creating books and writing academic articles, two tools that are mostly suggested are Latex and Pandoc.

Both are excellent tools for ebook authoring. I even have a plan to publish another book using Pandoc as a learning experience. However, there are things about those tools that are not so appealing:

They have a steeper learning curve;
Part of the syntax is counter intuitive;
And sometimes you find yourself type too much markup then writing actual text.

Being a geek, I love to play with new toys. That’s why I tried Latex and Pandoc for a while.

They were awesome. With one caveat: They were moving me away from my actual goal, i.e. writing the book, into the geekdom of learning and trying new and nerdy things.

That took me back to the “When in doubt, write the darn thing” rule that I’ll mention a few paragraphs below.

So instead of learning a new language just to write text, I chose a set of tools that I would feel comfortable and productive. The tools I used have changed over time. Here’s my current setup:

sublime text (distraction free mode): For the initial manuscripts where I only focus on the text and not on the formatting (bold, italic, headings etc.), nor the presentation.
iWork Pages: To bind the manuscripts as a book. It is monumentally better than MS Word. When I initially started writing the book in word, what I found was I started too much time reformatting code, and less time on the content – it simply did not work.
slexy.org: For highlighting the source code (because iWork Pages does not have a source code highlight support by default, but you can copy and paste formatted code, and it works just fine.
github: For maintaining the source code and tracking issues related to the book.
PayPal: To track orders.
A dedicated website: A site that only the readers can access, for them to download the updated copies of their books, along with any other items that I would be providing them.
iMac Mailer: For managing my reader base, and sending monthly newsletters.

Creating a (private) github repository was the one of the best things I did to get organized:

It was useful to keep track of the book’spublish cycles;
It was a central hub for the readers to conveniently access the book’s source code;
And, it created a medium to connect and exchange ideas with the book’s audience.

Not Having a Publisher Does not Mean You Are Free

Why? Because your community is your biggest publisher (we’ll come to that later). But apart from the book’s audience, you have another publisher very close to you: it isyou.

Treat yourself as if you are working with a publisher, because if you are self-publishing, by definition, you are the publisher.

Since nobody but you are the publisher, it means that the design, editing, proofing, marketing, distribution, and any other thing that you would do with a publisher is yourresponsibility.

It’s a hard job: You have to be highly motivated to create the best possible book. Also remember that you will need to sustain this motivation for a long time, to come up with the final version of your book. To stay motivated for such a long time:

Make sure that you’ve chosen a subject that you are passionate about,
And constantly engage and collaborate with your audience.

Do you see the similarity between having a startup, and self-publishing?
I’ll come to that later, too.

It Will Take a Lot Longer than You Think

After gathering raw data, and perfecting my publishing setup, I was pretty sure that I could finish the book in less than three months. I was completely and utterly wrong.

Writing a book is brutally hard; writing a technical book is harder; and it will cost you a lot of time.

If you good at time estimations (hint: most software engineers are not) multiply your initial estimate by three. If you don’t trust your time estimation skills, then multiply your initial estimate by five. Hitting version one of your book will take at least that amount of time, and possibly much longer.

The reason is simple: You are not a professional book-writer. You will be doing your writing on the off hours. And important life events will always interject your writing agenda.

For instance, your new job might require you to gather a new skillset and you might need to freeze contributing to the book until you gain those new skills; you might have a newborn baby who grabs your attention every time she’s awake; you might move to a new city, or a new country, or hell to a new continent!

I have been through all these and more in the last six months, and I can honestly say that it’s extremely hard to allocate time for a book during life’s ups and downs.

If do not see your book as your startup, then don’t even bother writing it at all. You will not be able to survive to the end of it.

If, and only if, your book is your startup; that is to say, it’s the most important thing that motivates you all the time, you will find time for it.

You Will Have Show Stoppers

Related to the former topic; it’s impossible to stay motivated, focused, and productive at all times.

You will have distractions.

In any side project that takes more than a few months, you need to have a clear set of guidelines to keep you on track. You need to have a ninja focus.

In addition to your fluctuating motivation and passion levels, you will also haveobstacles along the way: Some of them will be technical (such as how to format the source code, and how to choose the correct type face), and some of these problems will be behavioral (like how to stay focused, how to prioritize).

To overcome those obstacles carve the following three rules to the back of your minds:

Rule #1: Form Follows Function

Or content comes first.

The irony to design a great user interface is that you don’t think about the interface at all; instead you try to understand the user’s intentions, motivations, and tasks.

Why should it be different when you write a book?

Don’t worry about how to present your content. You will have plenty of time to decide about that. Once you focus on the structure only, presentation of it will turn out to be much better.

Besides, your book will evolve in time: You will need to add sections, remove sections merge sections, combine several sections into chapters…Don’t worry about them from the day one. It will paralyze you. The more material you have, the better idea you will have about how to present it.

If there’s only one thing that you should focus it should be writing:
Writing as much as you can.

When in doubt, write the darn thing. Worrying about styling, formatting, and presentation is a synonym for procrastination.

Rule #2: Share Early, Share Often

Just because you will be self-publishing does not mean that you won’t have any publishers. Your community (i.e. the readers of your book) is your publisher. They will be deciding the quality of your book; they will be giving feedback about it, and theywill be suggesting corrections and improvements.

Ask for your readers’ feedbacks. Revise your book; make corrections and editions based on those feedbacks. You can use those feedbacks later as “testimonials”, too.

Since you have nothing but your community, treat them well. And one way of treating them well is to regularly provide them with new material.

In my case “new material” is monthly newsletters, and monthly updates, new chapters, new drafts, and updated source-code. Those who opt in to be “editors” receive even more frequent copies.

Rule #3: Perfection is Boring; Laugh at It

Do not deal with problems you don’t have.

Believe in yourself, and be your biggest fan!

Declare a war on perfection; laugh at it. It’s boring and it keeps you from getting things done. If you are not producing any useful output for the sake of making things perfect, you are only fooling yourself.

Accept everything is constantly and continually in a draft mode, it helps to get it done.

Done is the engine of more; done is better than perfect.

This war on perfection also supports the “share early, share often”, and “write as much as you can; worry about the presentation later” guidelines.

Do you see how these rules relate to each other, and how they foster one another? It’s like the MVC of self-publishing. Without them you’ll have a hard time. Learn them by heart, and stick to them, always.

Building a Community is Harder Than You Think

By now, you are well aware that your readers are your community. You have to keep a bi-directional open channel to them; talk to them, and listen to them.

In deed, creating a community is really hard: If you have a group of readers who proactively respond to what you share with them, and give their valuable feedback, and support; then you’ve “done something”. And that “something” is not a community. It’s an “audience” at best.

Constantly think how you can turn your audience into a community.

The difference between an “audience” and a “community” is not merely semantic: A “community” is a living and breathing entity. Members of a community engageandbuild relationships with each other; they support one another.

The fact is there’s a tipping point, or an accumulation point, or a threshold number where your audience starts to become a community. Honestly, I’m not quite there yet.

If your book is going to be the hub for a major breakthrough; it should have a potential to establish a strong sense of community. If not, why bother writing it in the first place?

I’m an engineer (as well as a social media enthusiast). So if there’s a requirement; the first thing I would do will be to specify the elements of that requirement.

A “community” revolves around these element:

Membership (or fulfillment of being a member of something);
Influence (or the self-confidence in the belief that you can be a part of something and have influence on a bigger scale);
Integration;
Fulfillment of needs;
And a shared emotional connection.

I just want to elaborate on the most important, and often overlooked element: “establishing and fostering an emotional connection”:

Great communities feel a sense of connection through a shared state of mind. They rotate and oscillate with similar emotional frequencies.

One way to create a shared emotional state is through creating an epic, or a shared history, that the community can get their hands on, and take possessions of.

Frequently sharing ideas;
Increasing the quality of interactions;
And living (and creating) a set of experiences that members can gladly share with everyone else around them…

is the only ways to sustain the emotional connection.

All of which begets the question of “What a community is not?”:

Your Facebook Friends are not Your Community

I’ve dived into this much detail to underline the fact that community creation is not as easy as it seems.

Don’t force it. An organic-growing, closely-know, niche community is the most enduring one.

That’s why I intentionally, and purposefully, do not try to reach everyone. Target a “narrowed down”, elite audience whom you know for sure will learn from you, and add value to you.

Do not focus on building the community first. Focus on what you know best: “Writing the darn thing”.

One may argue “Build it first, and they will come” is a cliché; and clichés exist for a reason.

That’s a long reasoning why I haven’t added any social media buttons at all to the book’s site. That’s because my Facebook friends is not my community, nor is my twitter audience. At least most of them are not.

Social Media is Overrated

Here is the hard truth about social media management: it’s an oxymoron:

Social media cannot be managed, it’s saturated, and it’s overrated. Social media “manager”s who think they can “manage” social media are in a massive delusion.

Social media stems from the liberty, democracy, and wisdom of the crowds. It logically follows that “manageability” is against the very definition of it.

You cannot trust a fad, so the only reliable way is foster your community is do it the hard way: provide something of real value.

Even if your audience is ten people, treat them as a community. Engage with them, answer to their questions, probe their feedback, add value to them, and listen to them.

Your time and attention is limited, give them to those who deserve most.

Your core objective should be providing value, not promoting value.

Everyone will be famous for fifteen minutes. Going on the top page of Hacker News is overnight fame, and it will fade away in less than a week. Building a community is freaking hard work, and it will take years. Not everyone has stomach for that.

How to market your book is a non-issue. If you know that there’s a market for your book, and you can create an awesome book to beat the competition, and you have avalue proposition that no one else has, which can make you stand out anddifferentiate, do not bother marketing your book right now.

Remember? Do not deal with problems that you don’t have.

Your Book is Your Name, Treat it That Way

In the end, always remember that the way you market your book is a direct reflection of your name. And your name is your brand. In other words, if you spam others to promote your book, then that’s what you will add up to.

There is no sustainable business in spam. Do things the hard way, you’ll see that the attention to your book will, no matter how gradually it will be, snowball.

Your Book is Your Startup

What I have learned from this ongoing book-creation hassle is that books are like startups: You create a lot, you pivot a lot.

An as in every startup, it all begins with the idea that “you can be the change”.

By having a startup, you’re also an entrepreneur by definition, too. Don’t you feel your book, your idea, and your vision will stand out in the crowd? (If you don’t stand out, go home and come up with a new book idea.)

You are everything, the publisher, the copywriter, the technical reviewer, and the marketer.

Nobody has time for all these. Delegate as much of it to the community.

Being a Startup has its Benefits too

Everybody knows what a pain in the rear founding a startup is:

Being responsible for anything and everything of your product is like kind of a “torture”. On the contrary, nobody can deny the appeal of it: You are the master commander; you are on top of everything; when you succeed you feel legendary.

Actually, it’s not the success that makes startups appealing. It’s the instinct that you can be better, you can challenge the status quo, you can make a change, and you can be bigger than yourself. Otherwise it’d be plain stupid to dive into an industry that has 75% chance of failing. It’s not the success; it’s the experience that’s important:

Given that there are virtually zero barriers to entry, the chances of your book being successful is even lower than the success rate of a VC-backed start-up.

Conclusion

My starting point in JavaScript Interview Questions was the idea that “all those so-called ‘interview questions’ that people were forced to memorize so that they can trick the interviewer to get a job, was a complete nonsense”. Then I ended up creating a solid path to walk for those who really want to ace an interview.

I had empirical evidence that what the majority of the people were thinking about the interviews was wrong. What I had experienced during hundreds of interviews that I had been to supported that evidence. And I felt that by pointing out the elephant in the interviewing room, I could make an impact.

Do you know how to do something better than anyone else in the world? How would you let the world know about it? By writing a book, maybe?

Write a book, tell authentic stories. Make them as sexy as possible.

If you have read this far; then I assume you still have a passion, or an interest to write a book.

I’m not sure if your book will sell millions; I wholeheartedly wish it will. What I know, though, is that your book will change you, and it will make you stand out:

Writing a book makes you an expert in your field. At the very least, when you hand someone a book you wrote, it’s more impressive than handing a business card. Not only, it shows that you have enough expertise to write the book, it also shows you value the relationship with them enough that you are willing to give them something that’s dearly yours. Something you created.

You can’t say that you don’t have time because… whatever… you have a job to do, you’re running a business, you have to study your classes… so freaking what!

You don’t have time. You make time.

Good luck in your new book. And until then…
may the odds be ever in your favor.

Links get notes on Geeklist

Thu, 17 Jan 2013 05:19:46 -0500

It’s only natural. When we see a link we want to comment on it. From the first day we launched links the demand for leaving comments was deafening. So in Geeklist form, we built it. (well, actually Christian built it )

Now you can add Notes to links, sharing your thoughts and comments. Try it out! Go to your favorite community, select a link and leave a note. In light of the recent untimely passing of Reddit co-founder, Aaron Swartz, we felt link-sharing was our best tribute.

Please share links about Aaron in the Aaron Swartz community on Geeklist. We’re trying to gather all of his sites, stories and resources to share with the world in his memory.

Enjoy the notes on links… up next are notes on Micros and Cards!

It's 2013: If you're not using Geeklist to build relationships with or hire developers you're doing it wrong.

Wed, 02 Jan 2013 05:16:13 -0500

I’m not putting out many ‘marketing-ish’ type blog posts throughout the year. It’s not what Geeklist is about or how we like to share information. However, tonight I’m making an exception to that rule because many of you are still complaining that you can’t find developers to hire going into 2013. That’s because you’re doing it wrong!

The champagne is downed, the ball has dropped, we’ve all made our resolutions for the New Year and now it’s back to the grind with a vigor, passion and laser focus. Time to build new products, ship more code (preferably direct to production… at least if you’re at Geeklist) and plan out the product for 2013 and to do all of that you need more developers. One problem. The difficulty you had finding and building relationships with developers in 2012 has not gone away, because you didn’t know Geeklist works for building relationships with developers and hiring.

Unlike last January when Geeklist was still in private beta with only a few thousand users, this January we are on our way to 100k of the worlds best software engineers, interacting, high-5’ing, sharing links, announcing products, posting achievements, micros and connecting with companies.

Connections aren’t the only thing happening in Geeklist, though. Developers who want to find a new job for the new year are watching quietly to see what companies take advantage of the community and post jobs. They are watching and connecting with companies that get active, posting company achievements, linking to company blogs and news, adding team members and connecting with them directly. Relationships are being forged all day long and if you’re hiring you ought to be posting your job listings in Geeklist.

What are you waiting for? 2014? If you haven’t built your company profile in Geeklist, connected with some geeks and shared your company achievements you’re missing out on the most vibrant, social, active, live, connected and global community of developers that influence the worlds most influential companies, startups, investors and other developers. Just have a look at Bittorrent or Amazon R&D, New Relic or Blazemeter - all doing it right among hundreds of other companies jumping in.

Thanks for enduring this completely promotional blog post. Don’t expect more like it, but don’t blame us for being passionate founders making sure all of our followers (and some of their followers) know that Geeklist was built to help developers connect with each other and companies they love… and that’s happening right now, 24/7-365 days a year.

Sincerely - The @gklst Founders @rekatz and @csanz

p.s. - to go beyond job posting, reach out to us for sponsorship and collaborative initiatives at founders@geekli.st

The 10x Developer in you

Thu, 20 Dec 2012 19:52:00 -0500

A myth is going around in programming circles of a mythical beast called The 10x Programmer. These creatures eschew laws of nature, compared to average Joe Programmer they produce more high quality work in less time.

But are they really some special superhero? Born with a keyboard in their hands, mind made of linear algebra and visualising complex systems before they can walk? Or just normal people with an opportunity to actually¬†work?

I think everyone can be a 10x programmer.

Flow

Objectively measuring developer productivity is folly, but everyone can tell a productive day from a day wasted. You know, those days where you smash your brain against a bug all day and nothing seems to budge? Days when you come to work; there’s an urgent email, right after that an emergency phone call, then it’s already lunch time and … stuff happens. A lot of stuff. You’ve been busy all day, but you didn’t get any work¬†done.

Yeah, those days.

The problem with those days is you couldn’t achieve flow. That most awesome of states when you get to completely focus on the problem you’re solving, become so engrossed in the zone the program feels plastic in your mind. Fingers effortlessly gliding over the keyboard you can shape the code into anything you want just by thinking about it.

After four or five hours without a break, you feel energised, like you’ve just had sex or eaten the perfect piece of bacon (replace with chocolate cake at will) - hardly noticing any time has passed at all, you ask for more.

Looking back at what you’ve done … wow, it’s like you’ve been working for five days!

Hopefully tomorrow you will still understand the epic elegance.

This is called flow. It’s awesome. The only difference between you and 10x programmers is how often you get to work while in a state of flow.

Unfortunately, you’re a freelancer or an indie, this is hardly up to you. Especially for work projects.

Things that kill flow

Two things kill flow faster than you can say schadenfraude: you and your work environment.

Dealing with yourself is pretty easy, all it takes is a little discipline, gravitating towards projects you find interesting and a little discipline.

Discipline is important because of two things.

First and foremost, you must avoid working tired, working when you’re stressed and generally when you are unable to focus on what you’re doing. Things hanging over your head is a common problem. Deal with anything annoying, everything you’ve been putting off. Now!

Putting it off will not get it done, it’s only going to get worse. The best way to get rid of things you don’t want to do is to begin.

This clears your mind so it can focus on the code. Don’t believe me? Try. Handle all the annoying little bits and pieces in the morning and get to real work later.

Another common problem is The Internet.

Not much you can do here. I couldn’t code my way out of a wet paper bag without immediate access to documentation. But keep your compilation and test run times low, this keeps you out of temptation to get dragged into the world of funny cat pictures every time you press “Test”.

Use cat pictures as a barometer - if you see more than X in time span Y then you are tired. Get a break. Stop working. Your brain is trying to tell you things and it’s only going to get worse.

This gradual decline in ability to avoid impulsive behaviour is called ego depletion. Replenish your ego by stepping away from the computer and getting a proper break.

A good approach is the Pomodoro technique - focusing for 25 minutes, followed by a 5 minute break. This has enabled me to work all day without getting burned out after four hours and wasting the rest of the day.

Work environment

The most interesting project you can think of combined with all the discipline in the world can be completely trumped by a bad work environment.

Perhaps even more important, work/office culture counts as environment as well.

Trust.

That’s the main property of a good work environment. Without trust, things happen that kill a programmer’s productivity. What I mostly mean by this are interruptions.

While distractions are internal and can be avoided with a bit of discipline, the real problem are interruptions. Every time your boss asks what you’re doing, or checks how far along you are on that thing he’s asked you to do, they interrupt.

Every time a colleague needs their answer now, they’re interrupting. When an email must be answered now, same. Phone call, even worse.

Never¬†expect a programmer to respond immediately.

A good office environment will favour asynchronous communication. This allows programmers to respond when they have time, preferably in batches. Let requests accumulate for a few hours, even a whole day, then answer everything and don’t stop until you do.

This requires trust that you won’t just sweep things under the carpet and the developer’s discipline to actually respond to everything in a timely manner.

Managers like to check in on people, it makes them feel productive. It quenches their inner fear that programmers have wandered off and are spending too much time yak shaving and not enough producing valuable output. This fear must be quenched; again, trust. Trust that you will tell them as soon as you finish, trust that you will notify them when something starts taking too long … and you have to trust that they won’t bother you while you’re deep in thought.

Not to even mention the physical properties of environments - good lighting, comfy chairs, everything juuuuust right. Don’t share rooms with people not in your immediate team, don’t share rooms with people who use phones etc. etc.

So, 10x work?

It seems, then, that every each one of us can be a 10x developer. All we need is an environment that lets us adopt the right work practices and some discipline on our part.

Work in long stretches of time, avoid meetings, communicate asynchronously, take scheduled breaks, don’t worry about stuff.

You should read my book, Why programmers work at night.

Revamped Geeklist profiles just released

Mon, 17 Dec 2012 19:16:44 -0500

Today we are proud to announce the launch of a new cleaner redesign for your Geeklist Profile pages! As with many a startup we, too, have launched, discovered and iterated based on what we’ve learned from our users. In doing so we found that surfacing the information that our users were updating and sharing daily while pushing down some of the evergreen data will make for a better user experience. As the core of Geeklist remains our ability to let users share what they have done through Achievement cards and earn credit where credit is due, the use or creation of those cards is not a daily activity. It’s a milestone event and something which happens less frequently than say code commits into your Github repo or link-sharing using the GeekIt bookmarklet or GeekIt chrome extension.

So here is an example of the new profiles, this particular one is very complete with information, repos, communities, links and of course… Achievements (thanks Sean!)

What we have learned over the past months is that our most vibrant and exciting areas are in our Communities, Links and Link-sharing features like up-voting and re-geeking/sharing links to your most important resources.

The new profile pages are in the beta mode, so your comments and suggestions are very welcome - email us, use the support tab or just tell us right in the Micro stream on the main page.

Now’s a great time to go in and update your profile, link to your Github repos, share some achievements and get the companies you work with set up in Geeklist too.

- Geeklist Team

Ready, Set, Grow: Join us In Celebrating the Month of Movember

Fri, 02 Nov 2012 22:59:49 -0400

Guest blogpost for Geeklist by: Rafael Alenda, Director, Online Marketing, New Relic, Inc.

[Deploy from this link and Geeklist will match $10 for each install as well! That’s $20 to Mo’vember per install!]

It’s no secret that we love our product, our 30,000 customers and great causes. So when confronted with an opportunity to do something that included all three, we jumped at the chance. And we’re gearing up for the best November ever. Or should I say Movember.

A Great Month For a Great Cause

Based in Melbourne, Australia, Movember is a nonprofit organization that’s doing some truly great things to raise awareness and funds for men’s health issues — specifically prostate and testicular cancer initiatives. Each year during the month of November, more than one million men around the world — known as Mo Bros — begin the month clean-shaven, and spend the next 30 days growing and grooming their mustaches.

And We Think That’s AWESOME!

We are very fortunate to call Movember a customer. A little over a year ago, they contacted us to help them manage their very seasonal traffic and get deep performance visibility into their application. (Want to learn more? Read the Movember case study.)

Ready, Set, Grow!

So not only have the brave men of New Relic committed to risk, ridicule and awkwardness during these next 30 days, we’ve also agreed to donate $10 for every new deploy (installing a small and safe agent on your web server) during the month of Movember or to the Susan G. Komen Foundation. (We love our Mo Sistas too!)

If you haven’t tried New Relic yet but have a web app that could use optimization or speeding up, signup and start using our app monitoring service today. Remember, if you don’t have a production ready app, you can also install it locally on your laptop or pre-production environment.

We think you should “grow one” high and proud. New Relic and Geekli.st have teamed up to give Mo Bros and Mo Sistas like you a win-win opportunity.

When you sign up and deploy their agent into your app, New Relic will donate $10 to Movember on your behalf and Geeklist has agreed to match with an additional $10. Plus, you still receive a #nerdlife shirt from New Relic when you sign up by visiting the Movember page.

No purchase necessary or expected. Just a little way of saying “thank you” for your contributions to the future.

Already a customer? You can still help Movember by spreading the word to any and all your fellow nerds and developers that could benefit by using New Relic. We offer multiple sharing options here.

Supporting Movember in two unique ways

Thu, 01 Nov 2012 13:06:08 -0400

Just a few months ago I got the call from my father. They’d found some ‘abnormal’ cells and would need to do a biopsy… that day. The biopsy fortunately came back with no signs of prostate cancer, but it was a serious awakening for me and my father. I was quickly reminded of the importance of regular checks and knowledge. (Gain knowledge here) — So last week, when our friends at New Relic asked us to help promote their Movember drive I could not have been more excited. Geeklist has a culture of giving back and making lives of developers better. We hope this helps make someone’s life better too…

Throughout Movember Geeklist will be fundraising in not one, but two ways!

1: For every Job Posting placed on Geeklist we will donate $10 to Movember.

2: For every New Relic install via Geeklist we will donate $10, matching New Relic’s pledge of $10 per install. (See more information on their program in an upcoming blog post here) Yes. That means $20 per install made via Geeklist!

Yes. I will be growing a Moustache (much to my wife’s dismay) and I hope Geeklist can inspire you to get involved, grow a moustache, donate to Movember, post a job in support of Movember or try out New Relic and support movember 2x!

Thank you - Reuben Katz and the entire Geeklist family!

LESS is more and more is LESS

Sun, 28 Oct 2012 14:03:00 -0400

[Guest blog post by Jason Strimpel, Senior Front-End Engineer at Teradata]

Synopsis
This post will examine favoring DOM hierarchy replication using CSS LESS and fat CSS rules over CSS best practices to achieve more maintainable CSS in large web applications.

At your own Risk
I would like to preface this posting with a few disclaimers. I have only been using CSS LESS for a few months and I am not a CSS wizard, so please take these facts into consideration before posting comments like “Obviously you are an idiot…”, “WTF are you thinking…”, “You are the worst developer…”, etc. Also, this posting assumes basic knowledge of LESS. If you do not know LESS it only takes a few minutes to learn the basics. Lastly, any viewpoints and opinions expressed in this posting are mine (Jason Strimpel) and do not, in any way, reflect those of my employer.

Happy Tree
Before I get into the details I wanted to paint a picture of the environment in which I work. I am a front-end engineer at Teradata on the Viewpoint team. Viewpoint is the largest application on which I have worked. There are tens of thousands of lines of CSS. With that many lines of CSS specificity and inheritance conflicts are bound to occur, so maintenance and scope1 are primary concerns. On with the show…

A New World Order
Working with LESS for the past few months has caused me to rethink my opinions on what constitutes “good” CSS. For instance I used to avoid over qualified2 selectors like the plague because industry experts frown upon the practice. I used to place great concern on making my right most selector in a rule as specific as possible as well. I also used to break up styles into smaller classes that could be reused throughout an application. However, after using LESS for a few weeks and taking into account past maintenance issues and bugs I have begun to favor the following practices over CSS efficiency.

LESS allows you nest rules like blocks of code, which makes the rule’s inheritance and scope very clear. I have been using this feature to replicate the DOM structure to a certain degree. This is possible with standard CSS, but the inheritance and scope are not as clear and best practices advise against using over qualified/scoped selectors.
I have been creating fat rules that are composed of LESS mixins instead of creating a multitude of smaller rules and placing them together in an element’s class attribute. These mixins expand into CSS declarations.

Let’s take a closer look at these seemingly bad practices.

Rinse and Repeat
I tend to avoid duplication in general when coding. However, with LESS I find myself duplicating the DOM structure using selectors and nested rules. I am not saying that I start at the HTML tag and work my way down. For every view or widget I create there is a supporting LESS file. The widget or view always has a containing class, which is the root of the nested rules in the view’s LESS file. From there I replicate the DOM structure, for the most part, when creating rules.

https://gist.github.com/3969249

https://gist.github.com/3969256

https://gist.github.com/3969265

The LESS example is overly structured, but this eliminates specificity battles and conflicts with other views’ CSS especially when views are nested.

Fat Class Attribute Syndrome

Does this look familiar?

https://gist.github.com/3969274

This is very descriptive, but too verbose for my taste. I prefer to keep the DOM as lean as possible, so that all interactions with the DOM are more efficient. This also makes the DOM structure much easier to digest at a glance. However, due to its static nature CSS imposes limits upon a developer who is interested in style re-usage, which results in class attributes like the above. There are alternatives such as making each CSS class fat and specifying multiple long chains of selectors, but this becomes fragile and unmanageable over time when using standard CSS. It also results in a significant amount of duplication in the source code. So how does one overcome these CSS limitations? Enter CSS LESS.

https://gist.github.com/3969277

https://gist.github.com/3969280

https://gist.github.com/3969283

You’re an Idiot Jason
Yes. I am an idiot albeit not quite as dumb as you might initially thunk. Here are some arguments against structuring your CSS to reflect the DOM tree and using fat CSS rules over fat class attributes.

Your payload will be significantly larger – True, but if you are using compression and minification then the difference is trivial.
Your overqualified CSS selectors will be inefficient – Correct. However, if you are writing and maintaining a massive web application that is so optimized that CSS selector efficiency is causing you to lose sleep at night, then I want to meet you (contact me on Geeklist). I am not saying that you should completely ignore selector efficiency. I just prefer maintainability over trivial performance gains in most cases.
If your DOM structure changes you are hosed – Yes, but you are no worse off than if you used standard CSS. You will find it is actually easier to adapt to changes because you do not have to find all occurrences of a sequence of selectors in numerous rules and modify them. You just move a rule up or down levels.
You cannot write a CSS framework using this approach – Correct, but I am not creating Twitter Bootstrap (actually uses LESS). I am part of a team that develops and maintains a very large web application, so breaking the CSS into reusable classes for a larger audience is not one of my goals. My goals, in addition to performance and usability, are maintainability and less bugs.

Ship It
When you implement CSS best practices you are prematurely optimizing one of the fastest parts of the browser, the CSS parser. The cost of doing so in large web applications is an increase in the likelihood of specificity and inheritance conflicts. To me the benefit is not worth the cost when maintenance is taken into consideration. I would much rather reduce the probability of CSS bugs by over scoping/qualifying my CSS and focus my optimization efforts on something with a larger performance payoff like DOM interactions.

I have found that using LESS has encouraged me to write more maintainable CSS because by design LESS encourages “bad” practices3 or at the very least makes them easier to follow. It also has the added benefit of allowing me to write fatter rules that are easier to maintain than would be with standard CSS. As a result my HTML markup is much cleaner and easier to maintain as well.

I am not advocating throwing out common sense when it comes to writing and structuring CSS. There is always a trade-off and a middle ground. For instance, I still have generic global styling for things like forms and resets. What I am advocating is making maintenance a higher priority than CSS selector performance when developing large web applications. I am also advocating using LESS mixins to create fat classes to help make your HTML markup cleaner. I am advocating questioning industry best practices when they cause more problems than they solve as well.

Lastly, I am certain my ideas and opinions will change (hopefully improve) as I continue to use LESS. If there are any seasoned LESS users who disagree with this approach or have some insightful wisdom then please share. Just don’t be a troll about it. :)

If you are going to be in San Diego on November 16th drop by for some free food and fun, Lunch and Learn: Building a Desktop-Quality App on Web Technologies.

Notes

Scope meaning using CSS classes to name space CSS rules to help prevent conflicts
I am including unnecessary selectors in the inheritance chain in this definition
Practices that violate CSS best practices for CSS selector efficiency

- Jason Strimpel

How to Crack the Toughest Coding Interviews, by Gayle McDowell, ex-Google Engineer & hiring committee member

Fri, 26 Oct 2012 15:13:00 -0400

We’ve all heard the scary stories about Google interview questions. What would you do if you were shrunk to the size of a nickel and stuck in a blender? A man pushed his car to a hotel and lost his fortune — what happened?

The good news is that most of these questions are fake. The bad news is that the interview questions at top tech companies can still be really tough, especially if you aren’t expecting such questions

What to Expect in a Technical Interview

A typical interview for software engineers at top tech companies will be based in coding, data structures, algorithms, and system design questions. For example:

“Given two nodes in a binary search tree, find the lowest common ancestor of the two nodes.” — Amazon interview question

“Describe how you would implement the tinyurl.com website.” — Google interview question

“Given a cube with sides length n, write code to print all possible paths from the center to the surface.” — Microsoft interview question

“Design the data structures and algorithms to detect typos in a document and then provide suggestions to the user.” — Facebook interview question

These questions are designed to test your knowledge of computer science fundamentals (namely data structures and algorithms) in addition to your problem solving and coding skills.

And yes, experienced candidates should expect to go through a very similar set of questions at the top tech companies. They will not assume that you are an excellent coder and problem solver simply because you have many years of experience doing this. Sorry!

How You Will Be Evaluated

I frequently get emails along the lines of, “I was asked only one question at Microsoft and I got it right, but I still got rejected. Why?” There are at least two major issues with this question.

First, your interview performance can rarely be evaluated on a binary correct / incorrect basis. Instead, your interviewer will look at aspects like:

How efficient was your algorithm?
How well did you understand the tradeoffs between different choices?
How well did you communicate those tradeoffs?
How long did it take you to develop your algorithm?
How clean / readable / maintainable was your code?
How well did you test your code? How buggy was it?
When you found bugs in it, how did you go about fixing them?

None of these areas can be evaluated on a binary basis, let alone the entire interview.

Second, your interview performance on each of the above areas is evaluated relative to other candidates on the same question. That is, when I consider how quickly you solved the problem, I don’t ask if 15 minutes is fast or slow in general. That wouldn’t make sense. It might be really slow for one problem and really fast for another.

Instead, I compare your performance to other candidates. If it’s unusual to have a candidate take less than 20 minutes, then 15 minutes will be great performance. If most people can get the problem in 5 - 10 minutes, then 15 minutes will be considered quite slow.

So why did you get rejected even though you got your one and only interview question correct? Because “correctness” isn’t exactly an evaluation criteria, and because it might have taken you a very long time to solve the problem.

How to Answer Questions

You do not need to immediately spit out the right answer. I repeat: you do not need to immediately spit out the right answer.

When you get a technical question, try this approach:

Step 1. Ask questions

Make sure you actually understand the question you are asked. Validate any assumptions you might have. For example, is it a binary search tree or just a binary tree? What type is the array?

Step 2: Talk Out Loud

Did you read that first line? You’re not expected to immediately spit out the perfect solution. That’s just not feasible, for the vast majority of interview questions.

But you should start talking immediately, if at all possible. A brute force solution is a good place to start. Show your interviewer how you’re thinking about the problem. Brainstorm.

Step 3: Really think through your approach

Okay, you came up with an algorithm. Excellent. Is it a good one? What are the tradeoffs of your approach?

Remember that your interviewer may have asked this problem dozens of times. If there are issues with it, your interviewer knows what they are. You’re not going to be able to get away with pretending your algorithm is perfect when it’s not.

Step 4: Code (slowly and methodically)

Whiteboard coding (yes, you will more than likely have to code on a whiteboard) is not a race. You are not being judged at how quickly your hand can move across the board.

Candidates do get rejected for poor coding, but it’s not because they wrote too slowly. It’s because they stumbled through their code too much and make too many mistakes.

Start coding in the upper left hand corner (the far upper left hand corner). Write small — you’ll need the space. And watch for “line creep” — when your handwriting drifts downwards at a 15 degree angle.

Take your time. Breathe. Think about what you’re doing.

Pseudocode is not sufficient for most interviewers (though some will be okay with it). However, if it helps you, it’s fine to first write pseudocode as long as you’ll follow it up with real code. In this case, you should tell your interviewer that you’ll write real code afterwards; you don’t want them to think that you’re one of those “pseudocode-only candidates.”

Step 5: Test and Fix (Carefully!)

You wouldn’t check code in without testing it first (I hope!), so why are you avoiding testing in an interview?

After you finish your whiteboard code, test it. Run it through with base cases, extreme cases, and general cases.

When you find bugs (and you will!), that’s okay. Even the best candidates have some bugs in their code. Just take your time, think about why the bug occurred, and then fix it. Don’t race to put in just any ol’ fix. It might fix that bug at the cost of creating many new ones.

Don’t Panic!

Remember: if you don’t know how to solve the problem, that’s okay. Even the best candidates don’t know how to solve most interview questions immediately. You’re not expected to – really!

When you get stumped, brainstorm and discuss different approaches, even if they’re “bad” approaches. Your interviewer wants to see how you’ll approach the problem, so walk him/her through your thought process.

Struggling does not mean you’re doing poorly. On the contrary, it could mean that you’ve been doing so well that your interviewer asked you an extra tough problem.

Breathe. Think about what you’re doing. And do your best.

- Gayle Laakmann McDowell

Hacker Stories: Finding Playground.fm at #sfmusictech

Tue, 09 Oct 2012 20:37:00 -0400

Yesterday I stopped by Singly’s office to check on SF Musictech Hackday. The goal of the event is to build cool stuff that leverages existing music APIs. Here at Geeklist we love discovering new cool apps hackers are building and I figured it would be appropiate to share this more often via our blog or email updates.

Last night I found Playground.fm, a really awesome new app that recommends playlists from people who match your music taste. Quick view of their demo last night:

It finds playlists created by other users based on your music preferences across multiple different services like Spotify, Rdio, etc. When Vivek told me about it, I couldn’t believe no one has built something like this yet!

I’m super lazy when it comes to searching for music, I can never remember the names of new singers or popular songs, so I usually ask my friends or I shazam it if I spot something I like, but not the best user experience. Using Playground.fm was effortless, it was like having your own personal DJ who happens to also know your taste and played stuff for you

So this morning I interviewed Vivek and the team I asked them a bunch of questions about how he came up with the idea, how he used to develop the product, his biggest challenge, what was fun about it and how far he and the rest of the team wants to take it, etc.

Very cool team as you can see! Down to earth, very talented and they are all passionate about music. Perfect combination.

“Playground.fm finds playlists tuned for you. Listen to a personalized selection of music from your friends, world famous DJs, and people who share your taste in music. It’s a fun and easy way to discover music you’ll love, from music fans everywhere, while hardly lifting a finger” - Vivek Agrawal

After the hackathon I stayed I little longer and chatted with my friend Jason, CEO and cofounder of Singly and we talked about his product and the impact on developers. He is building a service thats basically making it super simple and easy for new companies like Playground.fm to build and integrate with APIs everywhere. He told me more about it in his own words.

“For Singly, it’s not only awesome to have these types of companies as customers but also to see them come together through our community and help each other grow their businesses. Geeklist, to me, is a place for developers to share their stories and accomplishments with the broader tribe of creators. And in this particular case, Playground.fm has a lot to be proud of with their product. People should know about it, how it came to be and join in an ongoing conversation with the team on what tools they use, what they are learning and what they are doing to push the envelope with the use of smart data, friend-finding and sharing” - Jason Cavnar

By now you are probably hoping you can try out the app right? Sorry to keep you waiting so long! Just know that Geeklist users are the first ones to try this new cool app! You are getting exlusive beta access.

Soooo to get in go here: http://www.playground.fm/geeklist

I’ll be publishing more stories as we discover more cool apps via hackathons or our own user base. If you have a new service to share, please send it to share@geekli.st and we’ll either give you really awesome feedback (if not ready prime time) or publish it for the world to see!

More behind the scenes screens

Enjoy it!

Christian Sanz

Free Pluralsight Training for Geeklist Members: Node.js

Tue, 02 Oct 2012 22:35:51 -0400

[Guest blog post and exclusive offer from Aaron Skonnard, CEO of PluralSight]

When I first stumbled across Geeklist, it seemed like a match made in heaven for Pluralsight customers.

The Geeklist community is all about socializing developer achievements, exciting code breakthroughs, developer-oriented companies, and building targeted communities around specific “geeky” technical topics. We think Geeklist is cool because it’s about empowering developers. And that’s precisely what Pluralsight is all about.

Pluralsight provides high-quality online training for hardcore developers. Our online training library provides developers around the world with instant access to a rich collection of on-demand courses taught by world-renowned industry authorities. Pluralsight offers flexible and cost-effective subscription plans for individuals and businesses starting from as little as $29 a month.

Given the similarities of our communities, we want Geeklist members to have a taste of our online learning experience. So we’re making two of our Node.js courses free to the entire Geeklist community. Once you follow @gklst and @pluralsight on Twitter, you can request a free activation code. Then, once you activate your free subscription, you’ll get access to the following two courses for a full month: Node on Windows and Azure and Web Development with ExpressJS.

Request your FREE activation code now!

Hurry, this offer expires Monday, October 8th. We hope you enjoy the free courses!