Coder. Speaker. Writer.

With the startup market taking off, there is always a clamor to find good engineers, developers, and designers.  People constantly ask if I know people, where to find the so-called ’startup-engineers’, or even where the can find someone like me.

Here are some things to think about for those on the recruiting side:

1. When to start recruiting?

Engineers love to build, solve tough problems, and make progress.  If you’re a founder who is still trying to grasp the product roadmap and create a company vision its probably not a good time to hire an engineer.  There are a lot of engineers out there who have been burned by founders who pull and push them in a variety of directions. We engineers know that need to be agile in a startup and be able to scrap code and rebuild, but want we don’t want is to have a founder who manic or aimless.

2. Sweat equity or salary?

Engineers are humans, we have bills to pay, families to take care of, friends that we want to spend time with, and on occasion indulge in the latest tech gadget.  Contrary to the way we carry ourselves we’re not robots (although I do enjoy being called a machine - but I’m not Summer Glau).  So before you ask someone to even spend an hour of their time writing code or reviewing specs make sure you can pay them in some form (coffee, dinner, laptop, etc.), and if you can’t then you better start thinking of ways to raise enough funds to be able to pay them something.  Don’t expect someone to work for nothing endlessly.

3. How to find them?

The vast majority of us are a lonesome bunch.  We like sitting at home or in coffee shops on our laptops coding away fun projects.  You won’t find us going out to the normal startup networking events or partying all night.  The best places to find us are at tech conferences or panels.  We’ll respond to recruiters on LinkedIn, but we don’t want to be treated like a commodity, and more times than not we’re very happily and gainfully employed.  While we’re willing to indulge to see what’s out there the opportunity has to be ripe enough for us to leave our current position.  Our sense of pride an accomplishment comes from being a part of a team and building something.  So we get attached to our team and product, and its hard to forsake that for another opportunity that we’re unsure of.

When people ask where can they find someone like me, it makes me smile.  The truth is I’ve been created and molded by my experience.  4 years ago I started playing in the startup space.  My motivation was to become a better engineer and knew that the startup space was where I’d learn the entire breath of the development cycle.  It was a tough 4 years filled with mistakes and hard work, but I loved it because I got to create something of value that impacted millions of people’s lives.  And over that time period I learned from great engineering mentors.

There are probably a lot more people who like me have a fire and a hunger.  They want to work hard and prove themselves.  I think its important to keep that in mind rather than always trying to covet a rock star developer with a proven track record.  It’s a huge risk to take on a junior engineer, but would you rather have someone on your team who is willing to learn, grow, commit to the company, and put in the long hours to improve themselves?  Or do you just want a code monkey?

4. Motivating Them

Engineers are motivated by a variety of things.  The most basic is a good company culture.  They  want to know that the founder cares about his team, and his engineers and will give them the resources to get things done.  They want to work on challenging projects but understand that there will be grunt work that needs to get done.  The key is to balance it out.  By letting them learn and play with new technologies from time to time.  We don’t want to work on the same things for months on end without any sort of end in sight.  Part of an engineers desire to solve problems is also a reflection of them wanting to improve themselves by becoming a better developer.  This is only possible if we have time to learn and improve our own thinking, and practice.

There is a reason people choose to become engineers, they want to solve problems mostly those related to systems, usability, and improving people’s lives on a large scale.

5. Listen to Them and Develop Empathy

I’ve seen too many engineers express dissatisfaction at changes in deadlines, product features, and increased workload without gratitude.  Or founders who want the impossible done as of yesterday.  Remember people only have two hands!  You’ve got to understand what engineers are capable of accomplishing and how quickly they can move.  If they’re coming up to speed with the product, development cycle, and company dynamics is good to let them ramp up slowly.  Yes, building software is cheap and fast unlike other products.  But there is still the overhead of testing, scaling, and securing.  So while it might seem like a simple feature should take a day to implement there is more infrastructure and thought that need to go into it before it can be delivered to an end user.

Engineers are good guys, they’re builders, refiners, and affect the course of history by improving human lives.  Its up to the entrepreneur to unleash their potential to accomplish great feats together.  Don’t think of them as code monkeys or worse yet commodities.

Tweet This Post

My last Ruby Tuesday post was pretty laudatory regarding prototyping in Rails.  In this post I’m switching gears and exposing the pains and limitations with Rails.

The development team at my current startup is composed of engineers and designers, basically I make everyone on the team write code  I understand that Rails’ benefit is in thinking from an MVC mindset.  But because it integrates all components its requires that all developers have some knowledge of a high level language (Java, Ruby), front-end technologies (HTML, CSS), and an understanding of databases.  While it doesn’t require them to have depth of knowledge I think the tight coupling makes it hard to separate the layers.

The following are the three limitations I’ve been experiencing with Rails:

1. Integration – when it comes time to integrate HTML or design changes, designers and front-end engineers need to work in the same space i.e. the same .erb.html file.  Yes I know it doesn’t require a painful and time-consuming compilation process like XMLC or Velocity.  But its easier for the designer to change the look and feel using XMLC or Velocity because they have defined a set of DOM objects.  With Rails designers have to understand views and partials.
2. Convention over configuration – the speed of development with convention over configuration Rails seems to come at the price of normalization, meaning there  is not foreign key construct in Rails.  You as a developer are required to configure this yourself along with other database constructs like unique constraints and indexes.
3. Deprecation – perhaps its just me, and I’m used to Java versions being released every year or two, but it seems like there are a lot of constructs that are deprecated between Rails versions.  The book publishers can barely keep up with the changes.  The other is that some of the constructs that are deprecated which I think are quite large i.e. scaffolding.

Despite these pitfalls I do advocate Rails as a prototyping platform.  The learning curve isn’t steep, and convention over configuration improves the progress developers can make in a day.  I’d also like to learn more about how people have addressed these pitfalls as their prototype matures.  What have been some of your experiences and approaches to dealing with Rails as you transition and build out the product?

Tweet This Post

I realize I’ve been neglectful in posting articles on Ruby development.  So back by popular demand I’m going to make an effort to resume the Ruby Tuesday series.

For the past couples months I’ve been playing with Rails and have been building my product’s prototype with it. The last time I created a prototype for a product I wrote it in Java.  The choice to write it in Java was simply because the founder and I knew how to write Java, and were more productive in it than C++.

After that experience, I spent sometime thinking about all the pains and positives I had experienced with Java and decided it was time to explore another technology.  Initially, I just wanted to know what all the buzz around Rails was about.  Ultimately, my choice to use Rails was based on the following:

1. Simplicity of Configuration: I started off as the only engineer on the project and didn’t want to spend a lot of time writing migration scripts, files to handle ORM, and having to setup all the mappings in a MVC framework.
2. Support and Documentation: the Ruby and Rails community has a great number of forums where people are constantly communicating and helping one another out when it comes to resolving issues.  As someone starting without a development team I think thats key, unless you have the luxury of constantly stepping out of your office to talk to another developer or attend meet ups.
3. Speed of Development: I don’t spend 10 minutes sitting around waiting to compile!  One of the biggest problems I had with developing in Java and all other high level languages was not being able to being able to make a small change and see its impact instantly.  I’d have to sit through compilation or figure out ways to optimize the compilation process.
4. Flat learning Curve: Now I do know the full stack of development technologies, so it took me less than a day to get an app up and running.  But I still found it pretty intuitive to setup and I wasn’t sitting around reading documentation for hours figuring out why I couldn’t connect to the database.
5. Emulation: I was thrilled when I discovered that Rails has a lot of AJAX and JavaScript functionality built into it because it has been years since I wrote a substantial amount of JS.  The other of course is you don’t want to have to constantly switch from technology to technology in the course of writing code.

I will say that as a developer who understand and can code a full stack development, and has worked in a MVC mindset, I’m able to debug issues faster in Rails than others who are purely front-end or back-end developers.  So for anyone evaluating Rails I’d recommend getting accustomed to MVC and thinking about development from that perspective.  My other suggestion is to understand how Rails tries to emulate other technologies like JavaScript and AJAX (using .rjc) and Hibernate/ORM (using ActiveRecord).

Finally, realize that there are limitations to Rails, and its important to be aware of them and be prepared to deal with them or find another technology to compliment Rails.

Tweet This Post

Having been an engineer at a startup I empathize with people who are being recruited into startups especially if it’s their first startup. The key deciding factor for me was that I wanted to learn everything about engineering a consumer product. Sure making bank is a nice motivation, but I quit my Masters at Stanford because I knew I’d learn a ton more working on the ground floor of a startup than I would sitting in a classroom. I still wholeheartedly believe that the only way I learn is by doing, which is why I’m starting a company instead of getting an MBA. It’s my MO but that doesn’t mean it works for other people.

The point of this post isn’t how to negotiate or what to ask for because it really depends on your needs (maybe I’ll cover that later). Its meant to paint a realistic picture of what life is like as a ground floor engineer versus past 10, 20 and 30+.

Being a ground floor engineer means you work everyday… 365 days at the very least for the first year. You’re expected to be a generalist, and its best if you’re passionate about the product. There’s just a shit load to do: features, infrastructure, testing, integration, bug fixes, mastering new technologies, bringing others up to speed on the architecture, interviewing candidates, and the list goes on. You’re on call, you fix everything big and small, and you don’t complain you just learn and do! The benefit is you have one of the biggest equity stakes in the company, but the bigger benefit is you know how the entire system is architected and the code you’ve written impacts millions of people! I chose this role for myself because I wanted to be a generalist and learn how the entire system was integrated and built (also why I majored in EE and CS). I also wanted to gain some insight into prototyping and how product’s evolved. If you’re a hungry geek do yourself a favor and don’t settle for anything over 10. Start early!

5-10 stuff is built… but you’re still adding a ton of value to the product and defining the engineering team. You might miss out on a lot of the business and product decisions that were made early on, but if the company is pivoting then it’s ok. You’re still going to play a heavy hand and have your pick of projects long-term.

10-20 this is when startups call in specialists. They are interested in hiring a front-end or back-end developer, algorithms guy, or architect. Not really a hacker-type, but someone who has a deep understanding of a set of technologies or a predilection towards a particular area. Its also one of the more risk averse positions because the startup has mostly likely gone through 1-2 rounds of funding and has gained user traction.

20-30+ get ready to scale and maintain! There’s still a lot of innovation going on, and its focused on scaling the system to support user growth. If you’re a young engineer you’re probably going to be thrust into the maintenance camp, learning the existing architecture first before being given your first juicy project. But hey its a startup and it’s making progress! If the founding engineers are still around you’re in luck because they’ll have a ton of knowledge to impart.

The biggest thing to think about when deciding what stage you want to start at is knowing personally how comfortable you are with change. New people starting every day, week or month, business goals and priorities switching courses, having new bosses, and your own workday context switches: working on a project to fighting fires and back to coding. The earlier you start the more change you deal with and the less time you have to really sit down and think through problems.  You’ve got to be quick on your feet,  and deal with the ebbs and flows – learn to adapt and accept. If you like stability start later.

Regardless of which position you do decide, a startup is a lot of fun, but it’s a lot of work.  It’s not a cushy job nor is it a way to get rich.  Its like buying a home: don’t be fixated on flipping it, picture  yourself living in it for the next 4-7 years because thats how long it will be if it’s going well.  Your teammates are the family you are going to raise in it, and you want to make sure you fit in well with the culture and community.  Most importantly make sure you buy  and believe in the long term vision of the founder.

(I was affectionately called #2 at Mint.com, because in the words of Aaron Patzer, “…engineers start counting at 0.” )

Tweet This Post

From the ripe age of 8 I’ve been thinking about my career, I aspired to be a lawyer, professor, and writer.  I read all the time and wrote stories for fun.  I had lofty goals of being published in seventh grade, but my dreams were curtailed when my family moved.   I can’t say it was all self-imposed because a large part of it came from having immigrant parents who really valued education and instilled a hard work ethic in me.  My mom for several years worked and went to school, and my dad never ceased to be reading a book on business or engineering.  The both of them spent a lot of time with my brother and I while we were in grade school.  In high school I rebelled, and didn’t want them spoon feeding me.  I often wouldn’t show my parents my report card or tell them what classes I was taking.  I just wanted to have time to explore.  I was studious enough that they backed off.  To me it was more important to have the freedom to be self-directed.

I joined the debate team because I wanted to be a lawyer, and figured I had to be really good at public speaking.  I also  learned Spanish because I wanted to be able to work with a wider variety of people and travel for work.  In college I TA’ed every year because I wanted to be a professor.  I made all these choices on my own, but I think they came from my parents instilling the value of caring about one’s path in life, and finding purpose.  They also instilled a healthy fear of mediocrity in myself and my brother.

Whenever I meet recent graduate from high school, college, and even HBS many of them don’t seem to know what they want.  It’s ok to not know so long as you’re moving in a direction of discovery.  They ask me for advice on majoring in engineering or being an entrepreneur; two careers that I never imagined pursuing but have naturally gravitated towards.  My response has always been to spend time thinking about what you like doing best, for me it’s reading, writing, coding, and speaking.   But there’s a bigger issue here, a lot of people don’t know what they are good at or enjoy doing.  They struggle with the part of just getting good at something.  The first step is discipline.  Pick just one thing to be disciplined about, and realize that you’re not always going to love doing it.  You start to love it as you build confidence, and the way to build confidence is to learn, practice, and refine.  In high school I primarily focused on debate, and in college it was engineering.  I spent 4 years in high school doing public speaking.  Everyday was spent practicing, thinking, and presenting in front of a variety of audience.  And I’ve spent the last 10 years learning, reading, and coding in order to become a better engineer.

Being self-directed implies having a plan of action, not one that is set in stone, but one that is focused on being good at the current job or interest.  This helps you focus on acquiring skills and experiences.  To me skills are just tools that you use to execute everyday, you learn from experiences and they give you the opportunity to hone your skills.  The combination of the two leads you to your ultimate goal of finding your calling.  But the biggest component is wanting to explore on your own, and picking a direction and sticking to it until you are no longer learning and improving.

Tweet This Post