Why Great Entrepreneurs Are Older Than You Think (2014)
forbes.com
forbes.com
I agree with the article, at least as far as technical knowledge goes. Some friends of mine who I graduated with are starting an Instagram for music app called Cymbal in Brooklyn, and I talk to them somewhat frequently about what's going on tech-wise. They're seed-funded and have runway for the next while, and have produced a really quality app. Whether or not they'll succeed, I don't know, but I know the quality of their work isn't in question.
My takeaway from conversations with their back-end engineer is that he's getting a lot of experience building an infrastructure from the group up that's taking a lot of traffic, learning what to do and what not to do by things failing. He's developing the "right way to do things". By contrast, my time at Twitter as a backend/fullstack engineer has taught me a lot about what that infrastructure looks like when it's mature, and I've learned the Twitter-approved "right way to do things". We're both learning what scalable robust infrastructure looks like, but while he gets the benefit of familiarity with every part of the stack and learning first hand what works and why, I get a huge jump in general knowledge with less details.
Which is arguably better? We'll only know for certain when I start my own startup in a few years, but my gut feeling is that the skills I'm gaining here by perusing scaled-up systems that face hundred of millions of requests every day will serve me more. I've learned so much about good ways to build things in just my past few months that have already radically changed how I face my own personal projects, that I can't imagine sticking with code I wrote before I had this knowledge.
I know the article is more about industry experience as applied to creating a network of peers and the business side of things, but I'm confident it extends to the technical side as well.
Thoughts?
It's also worth pointing out that you can use your industry experience to develop essential political skills, and I'm not talking about how to be a Machiavellian dick. If you want to be a good leader, work on learning how to inspire and influence people's hearts and minds to work toward a common goal. Learn how to ask good questions and really listen. Figuring out what the goal is and effectively communicating that with others is key, but if you can actually motivate others to push themselves to advance that goal, you're on your way to becoming a very effective leader. BTW, you can practice these skills on any level because it doesn't require position or power. It simply requires that you interact, listen to and conspire with your coworkers, especially the ones that hold power over you.
This is another vastly understated benefit of working at a company rather than starting a start-up.
You not only get to see what code at-scale looks like and deal with it everyday, but also management. You can either learn good or bad management techniques watching your own manager interact with your team. Same goes for how the org is structured and how the stresses of that structure trickle down to grievances at the Software Engineer I level.
You can spend 6 months in your garage building the perfect code for your startup, then get it out there and find out that nobody uses it, nobody cares.
You may work where you work and see a niche or idea that you can grow into your own thing and your experience can translate well.
I do notice you talk about perhaps creating your own startup in the future. One thing I found with that is some people get used to steady job etc and then when they try to start something up they arent prepared for the lifestyle change and unknown feeling, it can be a stark contrast to "security". I think it is wise to prepare for such a thing.
At the risk of being very unfair in my generalisations young programmers often come in one of 2 shapes: 1) They think people over complicate stuff. As long as you have talented people and maintain your common sense, you will end up with good code. 2) They have read many, many blog posts and books like Code Complete and they are sure they know how to "do it right". As long as you adhere to this process you will end up with good code. 1 and 2 are not incompatible, but for some reason I rarely see people who exhibit both at the same time.
I've said it many times before, but in reality nothing teaches you to be a better programmer than watching something you worked on (and thought you knew what you were doing with) collapse under its own weight over a period of 5-10 years. The problem with young startups is that either your startup fails in the first year or two (and you never get to see why what you did was a mistake), or it is successful and you end up being CTO before you get to see why what you did was a mistake.
This leads to people who fit (again) one of two patterns: 1) The serial failure artist who wanders from one project to the next, staying for a year or so, writing horrible code without realising it and then moving on to do the same on the next project 2) The "why are all my underlings so incompetent" manager who can't understand how the next generation(s) of people who joined the team fscked up everything beyond comprehension. It's not so difficult!
As I have some experience learning and teaching foreign languages, I have drawn some parallels with being fluent in writing code and being fluent in speaking a foreign language. Even native speakers take 15 years or more to reach an adult level of fluency and proficiency in a language. When you are learning a foreign language, you have to expect to spend similar amounts of time and to immerse yourself in the target culture before you can reach an adult level of fluency and proficiency. This is why virtually all students of foreign languages fail to reach that level.
It is the same with programming. It takes a good 10 years before you start to understand all the subtleties that are important in programming. If you surround yourself with other young programmers and only ever read your own code, you end up becoming fluent in a kind of baby talk of your own invention. Alternatively if you obsess with meta issues like process you will become like the guy who can talk for an hour on verb inflections but can't order a drink at MacDonald's.
Ideally, what you want to do as a young programmer (IMHO) is to immerse yourself in a mature culture of fluent and proficient adult programmers. Unfortunately because virtually every single one of us started out the same way (either becoming baby-talk masters, or obsessing with meta details, or god-help-us-both) there are almost no such extant cultures.
My advice (based on my abject failure to do so when I was young) is not to think about this as a "should I join a startup and get a lot of responsibility" or "should I join an established company and learn industry methods" point of view. Instead take a long term view of your apprenticeship. Accept that it will take the better part of a decade. Try to spend time in many situations. But above all, seek out and cultivate relationships with mentors who can help you grow. It can be in your job, but it doesn't have to be. Go to meetups with established programmers and trade beer for wisdom. Write as much free and open source software as you can and get feedback. Go to conferences and search for the people who look like they've already had their preconceived notions shattered a thousand times.
I think this might be the root of the benefit of being young and working at an at-scale company. I'm the youngest engineer on my floor, and the amount I learn from my coworkers is staggering. A lot of "a-ha" moments for me are status quo thinking patterns for them, and I get a lot from leveraging their knowledge in conversations and working on projects together.
> Try to spend time in many situations. But above all, seek out and cultivate relationships with mentors who can help you grow.
Well said.
The other thing to be conscious of is the silo you live in on a team at a large company like Twitter as an engineer. You don't have to think about much more than writing code. As others have mentioned, engineering is by far the easiest challenge at a startup as a founder unless you are doing some crazy high tech thing.
All that being said, if your startup is successful and you get past the seed stage, then yes, you will have a good idea of how to build an engineering culture and use practices that are known to work at scale.
But micro services will be a lot easier to get right and test.
Your point is well-made, there are a lot of benefits of micro service architecture, but fast startup with few engineers is not one of them.
That project was exactly that, fast startup with 3 programmers, one of who was doubling as the tech guy. It made a few hundred million and it is still running today in more or less unmodified form (it's a bit prettier now, but the essence remains).
Monolithical development has a fairly low ceiling of complexity before you drown.
Of course, one monolith is a bad idea. Probably need a handful of services -- especially separating long running background work from foreground work, glued together with a queue system.
It's interesting, I've learned a lot about what works at scale when you have thousands of engineers and by practicing some of those techniques on side projects I've learned what doesn't work when you have less than 10 engineers.
> For instance, micro services and an extremely complex distributed architecture will add a lot of overhead and points of failure when a monolith is probably the best route when you have a few engineers. In a startup implementation speed is usually the most important aspect of your development project. Hacking usually trumps engineering in terms of value-add to your infant company.
This is on point. The real question is -- will I learn the best technique for writing code in a monolith that lends itself to being converted to a microservice architecture.
30-somethings start companies which serve 30-something customers, or enterprise customers of the type they've worked at (where purchasing decisions are made by 30-something directors).
There are exceptions to those rules, but they're pretty consistent.
What's important is that entrepreneurs be consistently visible across age/race/gender/class/origin/etc demographics, so all markets are best served.
I find I am better at almost every area of business than I was 10 years ago for a number of reasons.
Learn and put what you learned to use, doesnt matter if you are young or old.
being a successful gounder requires many good years to get there. I recall seeing a number as large as 7-10 years. Combine that with the 6-10 years of industry experience, which most likely includes previous failed startups, it means they started in at least their mid-20s.
What I take away from this is - start the starting of your company early (20s) and if you keep at it, you'll be successful by the time you're 40.