Comment by jamesroseman | Hacker News Reader

Comment by jamesroseman | Hacker News Reader

For what it's worth, I'm a 20-something working in the industry while my peers are off starting start-ups.

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?

I would say that you should be very careful with putting your Twitter-gained engineering knowledge to use in a startup. In most cases as a startup you should purposely not do many of the things Twitter does. 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. You will most likely throw away a ton of code along the way in the early days as you discover your path to product/market fit. That and you will only have a handful of people actually using it. Most early scalability issues (into the 10-100k DAU range in my experience) can be solved easily by throwing hardware at the problem...

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.

> 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.

But micro services will be a lot easier to get right and test.

Have you ever tried building a web app in under six months and with three people? Step 1 is usually not "reading Apache Storm documentation".

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.

No, but I've built at least one project where I'm 100% sure that if we had not chosen the 'micro service' path we'd never have completed it at all. Mind you, this was in the early 90's and we called them administrators but the end result was much the same. Easy to understand components fit together with lightweight glue.

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.

Separating things into components is great, at least in-process where you can enforce interfaces with compilers. Managing deployment, versioning, and compatibility of 10's of networked services (aka micro services) is not a good way to spend time in a young startup...

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.

You raise a lot of great points.

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.

I don't know anything about your friends or their app, but one thing to keep in mind is that the quality of work in a young startup is rarely in question. Mostly the people who work at them don't know what questions to ask.

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.

+1. Priceless advice. Spoken like a true Jedi.

Well said. I'll only add a quote from my non-programmer cousin who was about to travel the world as an English instructor: "Teaching is like a second language."

Your comment reminds me of an article written by Peter Norvig, Teach Yourself Programming in 10 Years (http://norvig.com/21-days.html). I like how you said to think about one's career as an apprenticeship. This allows a person to be mindful that they are always learning and perfecting their craft.

> 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.

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.

I think you're absolutely on point. Working for an established tech company is a great way to accelerate your continued education. Just because you're not doing everything yourself doesn't mean you can't develop a broad exposure to ideas. Depending on how much access to source code and documentation you have, you can stand on the shoulders of many giants.

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.

> 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.

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.

from many developers i know who go from mature companies to startups, they all seem to come to the same conclusion that "the code is the easy part"

I completely agree. Knowing "what" to do is far more important than "how" to do it. Although obviously you want to get both right. But if you don't get the first one right, second one doesn't even matter.

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.

The hardest part of coding for me is starting, and pushing myself through the slog of details that wiser developers already know how to handle. It's difficult for me to really push myself when I can hop across the hall and ask the local greybeard how to fix a frustrating problem. That advantage is absent in most startups; self-reliance is vital. I learned a lot about process, communication, and organization in larger companies, but I've learned much more about software development at a startup.

I dont think there is a "better" in a grand sense, but probably for individuals.

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.

Reply on news.ycombinator.com