As you may have puzzled out from other responses here, that's a very personal question. You need to figure out the cultural details that mean something to you, then ask the questions that reveal them.
For some people that's vacation, for others it's safety nets, and for others it's engineering processes. Only you know what matters to yourself.
If you carry this attitude through a series of future jobs, you're going to demonstrate that you're a pretty awful employee. Not all work is exciting, and new hires are often going to get the worst of it until they prove themselves. If you can't suck it up for a bit and show some loyalty, then there's another candidate who can.
But realistically, you're very early in your career and can afford to burn some bridges and make some selfish decisions. Doing this once or twice isn't going to really stand out as a problem, so much as you taking a little time to get your bearings in the real world.
So be sensitive to your employer's needs (don't quit during a release crunch), and be open to any counteroffers they may offer as you tell them your plans, but do what you need to.
It's extremely hard to sell a novel "job title" as a consultant.
Most clients will want to see examples or case studies of your success in the role -- so that they can understand what you do -- and that can't happen until you get some clients. You'll have a very hard time selling it as "I've done this, that and the other thing in a few different places so of course I can do this for".
You either need to find the established title that already applies to the role you want (project manager?), capture the rest of the supply chain (digital agency?), or you need to stumble into a defining gig before you start marketing yourself.
You don't realize it yet, but you're expressing a ton of anti-patterns here. Not the least of which is an urge to prematurely optimize your project, and desire to invent your own new solution to a broadly (but not universally) solved problem.
Don't assume that you can anticipate where your scaling challenges are really going to strike. MySQL and Mongo are both more than capable of supporting your project for quite a while, and after you collect more empirical data on your projects growth and bottlenecks, you can start thinking about how to address those problems.
Hi, thanks for your reply. I like your answer. I am aware of the programmer's urge to over-optimize "all the things" for the million requests per second. I think I get that many times.
My issue is that, while learning, you want to make the best choice when it comes to the users data. My take is if one does not full understand a component of the stack, one takes precautions. For example, I might not be the best on setting up a couple of mysql servers doing replication and monitoring the whole lot. However, what one can do is use a service like RDS, where it takes backups for you, and you can restore, or spin up a new instances etc etc. Which is nice.
Having switched to Mongo a while ago (using Compose), I feel that I don't have that much of control. So yeah, just experimenting I guess.
As a full-time employee in the purely technical track, greater responsibility and pay would come through architectural and design roles.
If he really just wants to code, the best way to maximize income would just be develop a career as a consultant rather than a staff engineer. The biggest opportunities for writing code for a ton of money are in a few intense roles, usually associated with R&D on a core product. It's not easy to stumble into those opportunities, and if your friend had the skills to go down that path, he'd already know.
I imagine someone in a tiny town in Alaska would need more training on dealing with wildlife than somebody in NYC would. Their training on handling humans should be pretty much the same.
With the exception that rural people probably have more and bigger guns than NYC people.
Everybody has different needs and expectations. Some of those even evolve or 180 over the course of a single career.
Speaking to your own concern, the tradeoff is that many technical managers are only there because they fell upward. They may understand your job responsibilities well based on their own experience, but they may not be good at advocating for their team or understanding how team members might have different needs and productivity then they themselves delivered. They also might loathe and stress excessively over their own job, which is no good for anybody. You can have a great manager that happens to be highly technical, but you may often find that you have a highly technical manager who's an awful manager. So as you learn what they are, keep an open mind to the skills that are applicable to management itself --being a manager isn't the same as being a technical lead.
I think your intuition is correct when you suggest that this approach isn't scalable. It runs counter to the concept of "flow", articulated in Peopleware[1] 30 years ago and confirmed many times since then.
Sharing the pain has benefits, but you're almost certainly paying more in lost productivity on both bugs and features than you're gaining in insight and sensitivity. As a small and stable company, you can probably afford the loss as you learn more about your market and as you prepare for more organizational complexity, but it will eventually inhibit your growth and burn out many of your developers.
That's a fair point. The one constant in a startup is change. It may be that in the future we'll have developers only doing front-line support for beta features of our API.
Regarding flow, we don't have all of the developers doing support all of the time. We have one developer doing support at a time and rotate each week. This protects the rest of the team from having their flow I interrupted.
More than that, the links he gave talked about the entire company doing support, not just the developers. In other words, he misunderstood the point being made.
Putting the responsibility for tech support on your development team is how you increase your turnover rate.
Personally, I don't believe he's really doing that, I think it's just marketing.
If you pursue a specialization and get bored, you move on from it. There's not a lot of drama to it and a lot of your skills will be transferable. On top of that, it sounds like you'll naturally keep investigating new areas as you go along, so your own transition -- if/when it comes -- will be even easier.
Provided that you're drawn to something that can get you work, just go for it.
For some people that's vacation, for others it's safety nets, and for others it's engineering processes. Only you know what matters to yourself.