5 ms·

Being Senior mostly has nothing to do with the technologies per se. Its about being responsible enough, mindful enough, communicative enough, thoughtful enough,

Being Senior mostly has nothing to do with the technologies per se. Its about being responsible enough, mindful enough, communicative enough, thoughtful enough, and patient enough to lead large features/projects/directives. Its about seeing the potential problems/opportunities with something and speaking up. I have seen interns who can behave like senior engineers because they know how to take responsibility, talk with non-technical people, and tackle tough problems with confidence etc.

whamlastxmas 10y ago
I feel confident I have the maturity/mindset for all of that, but I don't have the technical experience or breadth to confidently say "We should use this tool for this purpose". My input for "How would you select the technology this project?" would be to evaluate the available skillsets of my coworkers and pick the most appropriate framework and libraries accordingly. This might mean making an API with Rails, a front end with React, and use Google's mapping API if it was some sort of mapping application. That's about the limit of my confidence in tech decision making. How much should we be writing tests? How much should those tests cover? What type of tests? Should we use Agile/Waterfall/etc? Do we need code reviews? Pair programming? Continuous integration? What should the deployment be like? What's the most appropriate database to use for this? How can we help ensure absolute security? What can we do to shave milliseconds from load time? How would we make ____ more distributed to handle high peak loads? Those are all things that seem pretty relevant to being senior, and I don't have answers for them based on personal experience.
- quantumhobbit 10y ago
  Just asking those questions makes you more thoughtful than most senior developers. The next step is knowing that you don't need the perfect answer, just something good enough.
- hluska 10y ago
  >My input for "How would you select the technology this project?" would be to evaluate the available skillsets of my coworkers and pick the most appropriate framework and libraries accordingly. This might mean making an API with Rails, a front end with React, and use Google's mapping API if it was some sort of mapping application. That's about the limit of my confidence in tech decision making. That's one hell of a good answer! Nice work!!
- existencebox 10y ago
  I realize you were possibly asking these rhetorically, but let me answer these questions for the sake of trying to let you see through the eyes of someone who does feel "somewhat confident" in guiding large projects; because I believe you'll find that you may have more intuition for it than you realize, and that at least for me there's been no Magic(tm) How much should we be writing tests? - How much do you need them? (Are you grinding out an MVP on very short notice, or setting down the foundation of a long running important project?) and if you need a more obvious signal, are you hurting from not having them? How much should those tests cover? - See the above; but additionally (and tautologically), what parts of the code do you worry about tests covering? What type of tests? -What type does your team feel comfortable with using and maintaining long term? Should we use Agile/Waterfall/etc? - See the above, additionally consider if the context you're in (because the powers that be over you incurr a LOT of constraints) really encourages one of these. Do we need code reviews? - See "how much should I be writing tests" Pair programming? - Continue to cite the above, as well as "does it work for your team" Continuous integration? - Is the overhead worth the benefits? (this is not a loaded question) What should the deployment be like? - Easy, robust, hard to fuck up, easy to clean up. I stopped here intentionally because your latter questions touch on technical decision making, to which I'd give unified advice: Get to know the space. Get to know your tools, then ask someone smarter than you :) Less glibly, someone else has almost always done what you intend to, if not many someone else's, and their experience is so fucking valuable I cannot emphasize it enough, this is also half the benefit of having a personal network. However, you need a mental model of the space to evaluate their learnings in your context, and that just takes playing in that space until you feel comfortable with it. I really hope this doesn't come off as a preachy rant, my goal is to address your final sentence; to echo my original statement, that I believe you can apply the experience you've gained as a dev thus far to the questions you claim to have no experience for (and you go so far as to demonstrate this e.g. your rails example); and even in absence or presence of that, leveraging your team and peers is invaluable for making "less bad choices", and you're already doing that by asking here on HN. You're already walking the path you are aiming for.
- devin 10y ago
  Many of the items you've listed here are more cultural than technical. Confidently saying "we're going to use this because I'm senior and I know it's the right choice" is something that I see as rarely being successful. It has its time and place, but it ain't something that you should be doing often. You mention bringing the right coworkers into the decision-making process, which is the more appropriate move. Now, of the items you mention not having an answer to, I can give you a definitive answer to a few: ;) - Do you need CI? Yes if it's helping you manage your risk. Do you need it for your 4 line bash script? Probably not. For an application your team works on regularly? It's 2016; Set up a freakin' CI server. - Absolute security? This doesn't exist. Manage your risk, and the risk to the business. See: http://scholar.harvard.edu/files/mickens/files/thisworldofours.pdf http://scholar.harvard.edu/files/mickens/files/thisworldofou... - Tests? Yes. As far as coverage and what type, again, manage your risk. Does decent unit-level coverage and a couple of end-to-end tests give your team the confidence they need to develop quality software at a rate acceptable to your team and the business? - Do we need code reviews? Dealer's choice, but manage your risk. If you're getting heavy on tech debt, or there are big holes in team understanding, and you notice work is slowing down as a result, you haven't been managing your risk. - Most appropriate database? Manage your risk. Have the conversations with the business that give you a framework for doing a meaningful evaluation. - Shaving millis off of load times? What value does this represent to the business? There's a cost/benefit analysis that needs to be done to determine whether two weeks of work improving the response time by 10ms produces noticeable business value. Perhaps there's a way to shave 8ms off the response time which will only take one day. How much are 2ms worth to the business? -- It's nice to have personal experience answering questions like the ones you bring up, but I would only say "nice to have". As the previous poster mentioned, senior is IMO about being communicative and thoughtful more than it is about being right all the time or having a lot of battle scars to show off.
- sage76 10y ago
  This is exactly the problem I have too. I get interview questions like "You have to design xyz system, such that junior devs can start building it. How would you do it?" I find it very tough to answer them unless I have personally faced the problem or if I have read extensively about it. Sometimes I think that startup experience doesn't prepare you for this kinda stuff. In the early stages, it's all about "Fuck it, just ship it." So design and all go out the window. This is what is happening in my current company too.
  - up_and_up 10y ago
    Break the problem into logical pieces. Delegate based on the devs strengths.
serge2k 10y ago
Those other skills do require technical knowledge to be able to do well.
znpy 10y ago
This is interesting: what defines 'entry level', 'junior' and 'senior'?

whamlastxmas 10y ago

I feel confident I have the maturity/mindset for all of that, but I don't have the technical experience or breadth to confidently say "We should use this tool for this purpose". My input for "How would you select the technology this project?" would be to evaluate the available skillsets of my coworkers and pick the most appropriate framework and libraries accordingly. This might mean making an API with Rails, a front end with React, and use Google's mapping API if it was some sort of mapping application. That's about the limit of my confidence in tech decision making. How much should we be writing tests? How much should those tests cover? What type of tests? Should we use Agile/Waterfall/etc? Do we need code reviews? Pair programming? Continuous integration? What should the deployment be like? What's the most appropriate database to use for this? How can we help ensure absolute security? What can we do to shave milliseconds from load time? How would we make ____ more distributed to handle high peak loads? Those are all things that seem pretty relevant to being senior, and I don't have answers for them based on personal experience.

quantumhobbit 10y ago
Just asking those questions makes you more thoughtful than most senior developers. The next step is knowing that you don't need the perfect answer, just something good enough.
hluska 10y ago
>My input for "How would you select the technology this project?" would be to evaluate the available skillsets of my coworkers and pick the most appropriate framework and libraries accordingly. This might mean making an API with Rails, a front end with React, and use Google's mapping API if it was some sort of mapping application. That's about the limit of my confidence in tech decision making. That's one hell of a good answer! Nice work!!
existencebox 10y ago
I realize you were possibly asking these rhetorically, but let me answer these questions for the sake of trying to let you see through the eyes of someone who does feel "somewhat confident" in guiding large projects; because I believe you'll find that you may have more intuition for it than you realize, and that at least for me there's been no Magic(tm) How much should we be writing tests? - How much do you need them? (Are you grinding out an MVP on very short notice, or setting down the foundation of a long running important project?) and if you need a more obvious signal, are you hurting from not having them? How much should those tests cover? - See the above; but additionally (and tautologically), what parts of the code do you worry about tests covering? What type of tests? -What type does your team feel comfortable with using and maintaining long term? Should we use Agile/Waterfall/etc? - See the above, additionally consider if the context you're in (because the powers that be over you incurr a LOT of constraints) really encourages one of these. Do we need code reviews? - See "how much should I be writing tests" Pair programming? - Continue to cite the above, as well as "does it work for your team" Continuous integration? - Is the overhead worth the benefits? (this is not a loaded question) What should the deployment be like? - Easy, robust, hard to fuck up, easy to clean up. I stopped here intentionally because your latter questions touch on technical decision making, to which I'd give unified advice: Get to know the space. Get to know your tools, then ask someone smarter than you :) Less glibly, someone else has almost always done what you intend to, if not many someone else's, and their experience is so fucking valuable I cannot emphasize it enough, this is also half the benefit of having a personal network. However, you need a mental model of the space to evaluate their learnings in your context, and that just takes playing in that space until you feel comfortable with it. I really hope this doesn't come off as a preachy rant, my goal is to address your final sentence; to echo my original statement, that I believe you can apply the experience you've gained as a dev thus far to the questions you claim to have no experience for (and you go so far as to demonstrate this e.g. your rails example); and even in absence or presence of that, leveraging your team and peers is invaluable for making "less bad choices", and you're already doing that by asking here on HN. You're already walking the path you are aiming for.
devin 10y ago
Many of the items you've listed here are more cultural than technical. Confidently saying "we're going to use this because I'm senior and I know it's the right choice" is something that I see as rarely being successful. It has its time and place, but it ain't something that you should be doing often. You mention bringing the right coworkers into the decision-making process, which is the more appropriate move. Now, of the items you mention not having an answer to, I can give you a definitive answer to a few: ;) - Do you need CI? Yes if it's helping you manage your risk. Do you need it for your 4 line bash script? Probably not. For an application your team works on regularly? It's 2016; Set up a freakin' CI server. - Absolute security? This doesn't exist. Manage your risk, and the risk to the business. See: http://scholar.harvard.edu/files/mickens/files/thisworldofours.pdf http://scholar.harvard.edu/files/mickens/files/thisworldofou... - Tests? Yes. As far as coverage and what type, again, manage your risk. Does decent unit-level coverage and a couple of end-to-end tests give your team the confidence they need to develop quality software at a rate acceptable to your team and the business? - Do we need code reviews? Dealer's choice, but manage your risk. If you're getting heavy on tech debt, or there are big holes in team understanding, and you notice work is slowing down as a result, you haven't been managing your risk. - Most appropriate database? Manage your risk. Have the conversations with the business that give you a framework for doing a meaningful evaluation. - Shaving millis off of load times? What value does this represent to the business? There's a cost/benefit analysis that needs to be done to determine whether two weeks of work improving the response time by 10ms produces noticeable business value. Perhaps there's a way to shave 8ms off the response time which will only take one day. How much are 2ms worth to the business? -- It's nice to have personal experience answering questions like the ones you bring up, but I would only say "nice to have". As the previous poster mentioned, senior is IMO about being communicative and thoughtful more than it is about being right all the time or having a lot of battle scars to show off.
sage76 10y ago
This is exactly the problem I have too. I get interview questions like "You have to design xyz system, such that junior devs can start building it. How would you do it?" I find it very tough to answer them unless I have personally faced the problem or if I have read extensively about it. Sometimes I think that startup experience doesn't prepare you for this kinda stuff. In the early stages, it's all about "Fuck it, just ship it." So design and all go out the window. This is what is happening in my current company too.
- up_and_up 10y ago
  Break the problem into logical pieces. Delegate based on the devs strengths.

serge2k 10y ago

Those other skills do require technical knowledge to be able to do well.

znpy 10y ago

This is interesting: what defines 'entry level', 'junior' and 'senior'?