[jarjoura]

I don't know, because I'm an engineer, but what I learned from Apple, was not the work I was doing, but it was from being surrounded by such brilliance. I would go to lunch (or dinner) with the guy who wrote the javascript engine. Or pop into the office, during a beer bash, of the engineer who wrote the original UIScrollView and pick his brain about why they did things a certain way.

The actual day to day work though, was pretty routine. I was mostly fixing bugs and rebuilding parts of features that had to ship in yearly timelines. Every project I worked on that wasn't canceled was spent in refactor mode for a good portion of the year. Let's rewrite this for 64-bit for example, or let's rework this for this new framework. The actual customer should never notice a change in the product, and usually the visual changes are subtle if any. Lucky few got to work on the shiny demo-able new features and even fewer lucky folks got to lead teams from their new products.

Lastly, most of the tooling that I got really good at and used to great advantage was proprietary except for Xcode and Instruments. :(

So leaving to go to a startup I literally had to learn a whole new set of tools and APIs. Then again, I learned so much more about how to build a product from the ground up at a small 11 person startup than I ever did at Apple.

At a company like Apple, I gained skills adding a feature to an existing product. At a startup, I gained skills building a product from nothing but an idea.

[onion2k]

At a company like Apple, I gained skills adding a feature to an existing product. At a startup, I gained skills building a product from nothing but an idea.

Being able to take an idea and turn it in to a product is a brilliant skill that startups absolutely need, but equally, once the product is out there being used, you need the other skill set to maintain the product and add new things without annoying the users. Having people around who can do both is exceptionally useful because it means the team continues to do productive work for much longer without having to bring new people in.

To that end, I always recommend people get at least a few years experience at an established company before joining a startup.

[m12k]

I started my career in a startup, then did a two year stint in an established company and I'm now back in another startup. I got significantly better at reading code and debugging at the bigger company, but I didn't enjoy being a small cog in a big machine as much. I think it's good for people to get some experience with both - but I don't see why the order is important. I would argue that a startup, if it's successful, will soon enough grow big, so you can get to try both that way, and if it crashes and burns, an established company is a great place to land when things get chaotic (and in my case, to cool my feet and get my bearings before jumping into the next startup adventure).

[sown]

> Being able to take an idea and turn it in to a product is a brilliant skill that startups absolutely need, but equally, once the product is out there being used, you need the other skill set to maintain the product and add new things without annoying the users.

But guess who gets the glory? :(

[nerdwaller]

Frankly that's a potentially dangerous state of mind. Impulse you rather accomplish something little and get the glory or be on the team that got man on the moon?

In my opinion, it's amazing what you can accomplish when you don't care who gets the credit. You're stronger with others than on your own.

[sown]

> Impulse you rather

Not sure I understand.

Anyways, I've been around engineering teams for a while now and here's what I mean: there's always some principal engineer or fellow (in the terms of a title) that is greatly esteemed and admired because of decades of progressively larger and larger feature creation and system architecture/leadership.

If all I ever do is fix bugs -- forever in my career -- it means I'm not going to build anything and I don't get to be on the team that gets the people to the stars because that team is reserved for aforementioned team of people who have built a lot.

I probably shouldn't be a programmer anymore since all I'm good for is fixing bugs.

[onion2k]

Not you, but it's not you regardless of where you work if you're an employee. Glory comes from public recognition of your work. If that's what you're looking for, start something yourself. Or contribute to an open source project. Or write a book. Do something that will have your name put on it.

If you're working for someone else, and it's their name on the product, ignore glory and insist on money.

[sown]

> ... start something yourself. Or contribute to an open source project. Or write a book. Do something that will have your name put on it.

You say this like I've not thought about it or tried it myself. :)

It's difficult since I don't know what I don't know. I stumble around trying to figure out what I need to figure out and come to realize that I don't know what goes where.

It's also difficult because of sheer time. I spend 13-14 hours going to work, being at work, or coming home from work. Whatever suggestion you have I've probably thought about or tried, so do be considerate if you decide to reply. ;)

[manigandham]

If you want the glory, you're either in the wrong position or the wrong industry.

[collyw]

"Fixing bugs and keeping the thing running" never sounds as impressive on a CV as "created this product from scratch using ....".

That's how I interpreted what was being said rather than expecting fame in the hacker community.

[jarrettlenox]

This is the best comment that I've seen in a long time. Thank you. Kudos. I hope that you're successful and happy.