HN user
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.
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.
Which of the above suggestions wouldn't apply to both?
I understand what you're saying in general, but there are a lot of universals that would apply across all kinds of jurisdictions.
You recognize the irony here, right?
You won't give everyone the benefit of the doubt, but only take seriously the people who offer it to you.
That strategy doesn't seem like it would pan out very well!
There's a real difference between a Customer and a QA member, though. You can't demand leave the responsibility to make a good report on a customer because they're external to your organization. But you can do exactly that with the QA member because it's precisely their job to identify and describe defects.
You can indeed say "it works for me" to the QA member, and it's their responsibility to identify the environment or series of steps that reliably produce a failure. From there on out, you can no longer say "it works for me" because it doesn't: you finally know how to make it fail and now it's your job to figure out why.
And like I said, nascent startups with just a few founding engineers are a necessary exception. But the QA or Customer Support hire should come very early! Too many organizations stall on that, and they waste tons of opportunity and productivity by doing so.
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.
I personally agree with you, I just find that you/we are in the minority as hiring managers.
When you hire a PHP person to join your Ruby team, you're making a bet that they're able to ramp up on the new environment as readily as you and I might. I've seen great engineers fail to make leaps exactly like that one. The weirdest things can hang some up, and it can take quite a while to recognize and address the issue. It can cost quite a lot more than holding out for the right candidate. Sensibly or not, that's a risk that a lot of employers aren't willing to accept (or maybe aren't able to).
What mitigates the risk for these employers is if the candidate has other ready skills or has a track record of picking up plethora of skills like "C, Ruby, Java, C# and others" as you describe. I tried to express that in my original comment, but maybe didn't do so as clearly as I'd hoped.
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.
otherwise merit-based processes
What a delightful thought experiment! In the meantime...
Not really. For internal use as algorithm fodder, they've got millions of photos to harvest from Bing. And for external use, they can't confirm that the submitter actually had the rights to the image in the first place, so they aren't safe using them.
Do you think there's really an answer to your question that would make you reflect on the issue?
If so, what might the answer look like?
If not, why did you ask the question?
You generally need to bring an applicable skill to the table immediately on hire. With the exception of a few stable mid-sized companies that really love generalists and cultivating long-term employees, and fresh-grad hiring, most places can't take the time to ramp you up on a new skill AND their codebase before getting value back out of you.
But it also depends on the distance between skills (frameworks < platforms < languages), whether you know the industry or applicable business logic already, the breadth of your resume as a whole (a proven generalist vs a transitioning specialist).
But most importantly -- you can't really know from the outside -- don't be afraid to burden them with your resume. Worst case, they'll throw it out immediately and forget they ever saw it. Best case, they'll be in a pinch or spot a detail in your resume that you didn't even know they were looking for.
Deciphering bad bug reports is absolutely a waste of your time as a developer, but that doesn't imply that the user is mistaken. In nearly all cases, the user is correct in sensing a bug but incorrect or inarticulate in their description of it.
It's almost always a good idea to understand what's behind the report. It's just that somebody in a different role should be doing most of that work.
If an organization is having developers triage vague bug reports directly from end users, they're already in trouble.
Not only are developers a very expensive resource, they're generally not good at doing what you describe here. Nor are they usually well set up for it as their systems/devices are often tainted with development and debugging tools.
We can't make end users deliver bug reports that are detailed and reproducible, but (whenever possible) developers should only have to worry about reports that have those qualities.
Any organization that's grown beyond a couple founding engineers needs to have a layer of QA or Customer Support that's responsible for everything that you describe. It's a layer that not only pays for itself but also keeps both users and developers happy.
1. Figure out what sector/industry you'd like to work in.
2. Figure out what's popular in that sector
3. Focus your skill development on that.
With some exceptions, but there's a high affinity for certain technology stacks in most sectors.
Alternately, if you want to work with C or Haskell -- start by identifying the sectors that are actually using those (they do exist), and build your understanding of the problem domains unique to that sector or your familiarity with the frameworks, libraries and toolchains that are being used on top of them.
Whatever strikes your fancy. If you're pursuing startup culture at your age, and you aren't trying to become a developer/engineer yourself -- you have all the freedom in the world.
You've probably got more honed skills to contribute actively, and you won't have opportunity to make especially useful contributions programming in anything that's widespread. So you can dable in something popular to be able to read it better, explore something esoteric to have something novel in your toolkit, or just pursue something that's personally practical like the systems scripting and web stuff you've already been toying with.
Don't overthink it. Just find the one that gets you excited and spend whatever time on it you'd like.
Given where you are in your career, you're inevitably a high-risk person to hire for contract work. That means that at least one of the following will be true:
* you'll be ignored by good clients that can afford to avoid that risk
* you'll be score low pay to compensate for the risk
* you'll be hired for "good" pay by bad clients because they don't know what they're in for.
* Nobody will hire you and you'll watch the months go by without making money or developing a portfolio.
None of these are especially great for you!
For now, you'll learn more and make more if you look for a job for a bit first. If circumstances or preference make that impossible, you have two options:
* reach out for opportunity through your networks - friends, family, local events
* list and/or bid your services through markets like elance, odesk, or Craigslist
Then again, if I'm hiring a rockstar engineer ... If all they want to do is come in for 6 months and crank out some projects and leave, I'll probably still be grateful to have them for that time.
In 6 months, you won't know that your hire is a "rockstar". You'll know that they were opinionated and that they took initiative. You (and they) won't learn about the technical debt, unmaintainability, and latent carnage they left until well after their gone -- which is probably what happened at their prior employers as well.
If they really ever proved themselves to be that great, some prior employer would have paid them mountains in compensation just to keep them around and their resume would probably looked different.
Tenures too short? Maybe they delivered a lot of value in 6 months and were ready for a new challenge. Would you not hire a builder to build your house because they did the last one in 6 months?
No, but I'd be hiring a contractor if that's what I was looking for.
While you may not feel privileged because you had to make hard sacrifices, not everyone is in a position to make the sacrifices you made.
But even then, your anecdote only speaks for yourself. There are many people who are indeed privileged by exceptional class or talent and who don't even need to suffer through the sacrifices that you did. Doors have been swung open for them their whole live, while others (like yourself) have to open those same doors with a crowbar, and others still (like the OP's 8/10) will never even get to see the door.
1. Don't use the same password everywhere.
2. Use a password manager like LastPass or 1Password.
Regardless of the incidental security risk of showing those rules, the site shouldn't facilitate your irresponsibility when it comes to password management.
Talk to your supervisor (or theirs) first!
They've spent the time to hire and ramp you up one their processes and code. Unless you're terrible at your job, they don't want you to walk away. So tell them that you're feeling burnt out because X, Y, Z and that you want to see if there's a way to make things more satisfying for you.
It's really sad when a good engineer leaves a team without having shared their concerns ahead of time. One of the most important and satisfying roles of a manager is to help in situations like this, but they can't do that if you don't give them a chance!
Have you taken any vacations? Are you maintaining work/life balance day-to-day?
Your job can be tough, it can be discouraging, and it can make you feel responsible both for and to a ton of people on a ton of different levels. But you need to make sure you're taking care of yourself along the way.
If you're like most founders, you're probably overworking yourself and burning out. Of course you're not going to see the path to success once you've done that. Take a few days off and do something interesting and self-fulfilling. Then come back and take a fresh look. You may be surprised at how much more optimistic and ready you are.
1. Previous experience seeing technology projects through their full lifecycle, so that you know what you're facing and can communicate it to others before you get there.
2. Confident and strong rapport with your stakeholders (CEO, board, investors, etc), so that you can get the resources you need and so that you can feel comfortable delivering harsh news when you need to.
3. Leadership and rapport with your team, so that they're contributing as best they can.
4. Humility, so that you know when somebody else should be architecting, coding, hiring, estimating, managing, planning, or doing whatever else your job requires.
You have to inspire people to work hard, long and sometimes grueling hours to deliver.
You're doing it wrong. If you're having that much trouble with deadlines and bandwidth, you should be inspiring your CEO, board, and investors to solve that problem. You should also make sure that you're providing them with honest estimates and not over-promising what your team can achieve.
Even if they do it willingly, pressing so hard on your team is going to lead to burnout and turnover in the long term, and lower quality deliverables in the medium term. Those almost certainly cost your startup more than a postponed feature or missed deadline.
A good interviewer isn't looking for somebody that's suave and comfortable in the interview. They understand awkwardness, nervousness and that it's easy to make stupid technical and social mistakes under pressure -- and they may even relate to it.
But they still probably make a 95%-accurate assessment in those first couple minutes.