8 ms·

I am 1 month into my new position, same position you're in - new stack & straight into senior role. My tips so far: 1) Take over all the admin stuff you can to

• Jedi72 9y ago
  Also I'm assuming this is a web app but taking over a live project is a bit like getting handed a gun, you should check if it's loaded before handling it ;) at the least run a vulnerability scanner over your app to look for security issues
  • kovek 9y ago
    What are some examples of vulnerability scanners you are thinking of?
    • OliverJones 9y ago
      Burp scan, zap scan are two products for penetration testing / vulnerability scans. They mount organized attacks on your web site. They look for stuff like sql injection and xsrf, and all that. Burp has a broader scope because it does fuzz-style random testing. Zap is more reproducible. (Burp can be a pain in the neck because it doesn't reliably retest stuff it found.) Be gentle with your new developer colleagues as you present them the results from these tools. They almost always find a couple of more-or-less silly vulnerabilities.
• joelbirchler 9y ago
  >> I just started writing a summary of our standups and told them they didnt have to do it individually any more, >> it was appreciated and mgmt still get the info they need. I'm skeptical that management would need a daily status.
  • ErrantX 9y ago
    1.5) convince mgmt they don't need a daily update any more
    • nikhilsimha 9y ago
      1.5 b) convince management that don't need a management anymore in a <10 person startup.
      • Jedi72 9y ago
        This is actually the case and I probably misused the term, mgmt is actually the founders trying to find out if the features are going to be pushed before the next client meeting 90% of the time
        • throwanem 9y ago
          They're requiring reporting into three different tools, and still don't have the visibility to know if shit's going to be done by deadline? They really have no idea what they're doing. How are these deadlines getting set?
  • Avalyst 9y ago
    Especially in a <10 person team
  • MaulingMonkey 9y ago
    You don't need nightly builds either - but they can be useful. Shorter feedback cycles / faster iteration has a lot of benefits. Also depends on how far up the management chain you're going. If you've got critical bugs live in production, "management" may be the ones ensuring all the hot potatos are in fact being handled by someone - that nothing is falling through the cracks, that everything is being addressed, that QA is on top of testing hot new changes that need to be rolled out ASAP. Daily isn't frequent enough in this context. Burning through the QA backlog leading up to a big release in ye olde milestone driven waterfall style schedule? Daily might be frequent enough. Long term feature work? Might be able to go weeks between updates - but a daily ping of "still working on X, still on schedule" takes what - 5 seconds to email, 5 seconds to read? Helps keep the mental burden of juggling everything in your manager's head down, maybe helps reassure them you're not going to pull a "so yeah, we've still got a month of work left at least" on delivery day when they're reporting up to their management. They might not be able to help you get your task done faster, but they might be able to rearrange other parts of the schedule to keep their stakeholders happy (e.g. X is running into delays, but we can give you Y ahead of schedule). Even if they can't do anything to help the schedule, they can start managing expectations ahead of time, prevent unseemly "surprises." And hey, daily status reports are better than daily status queries.
• superplussed 9y ago
  I love all of your advice, but I would start straight-away with writing tests. Not only is it low risk, it is the best way to start understanding the code base, and gives you an avenue through which you can start introducing small refactorings. The other important thing is that developers LOVE to have outside help with testing and a pair of fresh eyes to look at the test-suite through.
  • rurban 9y ago
    Some times tests, but sometimes I start writing/improving the docs and tutorials, if they are in a bad shape. Mostly they are. Plus of course improving the infrastructure. This is also mostly in the same poor shape as the docs.
    • superplussed 9y ago
      Yeah, whenever new hires complain about the lack of completeness or correctness of documentation, I'm like: that's a great place for you to start. It also seems to be a great signal of the attitude of the new hire, because the people who kind of groan at that task usually end up having problems.. but that's another topic altogether.
      • verall 9y ago
        As a (junior) new hire in a group without very complete or correct documentation, I'm not sure I can agree with that. It can be nigh on impossible to try to improve documentation for complex systems without a very deep understanding of the stack. I could spend hours writing documentation but it's not useful when I don't know what is and isn't an intended behavior. I think a fresh face is a great asset to have for writing docs but they need someone with a very good understanding of the system to work with them. Some of the most frustrating times I've had had a junior dev have been documentation tasks for things I did not know very well, spending time poking the system to gain understanding and more time writing clear docs, only to hear that my docs are 'not how it works' and I had either setup and configuration wrong or need to file bugs so it works how it's 'supposed to', even though that is the exact documentation it's lacking. Maybe this is different for projects with less technical debt, where if the current behavior was documented that documentation would be useful. I think this habit of giving documentation tasks to the least knowledgeable people on a project, even though it's reviewed by those with more knowledge, makes the docs suffer.
• sidcool 9y ago
  Super useful. Thanks. The project is also in burning condition, viz. Tight deadlines, pressure etc.
  • JoshTriplett 9y ago
    "burning condition" should not be a persistent state. Job #1 should be getting it back to a healthy state, where people feel comfortable working normal hours.
  • tboyd47 9y ago
    Also talk to your QA and make sure they understand the level of throughput possible for your team. QA can unintentionally kill a struggling project by overloading the tracker with bug reports.
• bollockitis 9y ago
  Great tips, but I would add that those 2 hours spent exploring the code can actually be useful. I often need to read the code a few times before the big picture starts to come into view, so unless I need an immediate answer, I usually prefer to dig for it myself.
  • baby 9y ago
    I'd say it depends: * How important the code path is. It might really be some boring code that you will never touch or don't need to understand anyway. * How much time you have. This point is really important if you're reviewing some code.
  • sabelo 9y ago
    I found it easier to get a new project if you focused on support tickets as a new hire. It is quite something to be able to be productive and see some dark corners of the stack earlier on.
  • planteen 9y ago
    I think digging into the code for 2 hours solo is very important. If you still can't find it, ask a senior dev. Actually being familiar with the code is important to be able to nail down how things work abstractly to the actual implementation. Code is the ultimate source of truth. You are going to reach a point where you come to code written by an engineer who has left and nobody else understands. You will also need to dig into an open source project at some point without any help.
• WrtCdEvrydy 9y ago
  Additionally, start up a refactoring project on a feature branch. Seriously, the most useful thing I've ever done is just refactoring half of a project to see how it works.
  • gjjrfcbugxbhf 9y ago
    The existing devs will hate you. They already knew how it worked - now they may not even you've finished - and unlike normal refactoring you never knew how it was supposed to work. This is a good way to cut the velocity of whole project so you don't look as lost though.
    • daveguy 9y ago
      I don't think the point is to move the refactor into production. The refactor is a learning exercise. But if you start on the least understood, ugliest parts of the code the devs might welcome a refactor of those bits.
    • WrtCdEvrydy 9y ago
      Note, I did not say "commit to Production". Just set up the feature branch and tear it apart. Most code out there has 0 comments and uses conventions from when it was written (god help you if it's a legacy product)
  • maxxxxx 9y ago
    I sometimes do this with code that nobody understands but generally you should first talk to the people already there and understand the code.
    • WrtCdEvrydy 9y ago
      Note, I did not say "commit to Production". Just set up the feature branch and tear it apart. Most code out there has 0 comments and uses conventions from when it was written (god help you if it's a legacy product)
      • 9y ago
• rmchugh 9y ago
  regarding 1), isn't there a danger that you can end up being seen as an admin monkey by the rest of the team leading to them undervaluing your technical knowledge? I'm sure that they appreciate it, but that's not necessarily the same thing as it's good for the team in the long run.
  • cylentwolf 9y ago
    The trick is that then he is the throughput of his team into all the systems. So he can see if someone is having trouble with a bit of the code i.e. they haven't finished a part of the project. The Senior Dev can then pair code etc to help out. This will assuage the admin monkey syndrome when an answer comes up. But the answer is brilliant cause it also gives him the ability to see what his team is working on and how they are working on it.
• vayarajesh 9y ago
  Really great tip!
• sidcool 9y ago
  A very good idea. Thanks!
• cubano 9y ago
  As I have written in previous post, this is where IMO a step-debugger earns its keep. As an IC basically my entire life, I have joined large legacy projects many times, and my typical attack strategy always revolves around a large cup of coffee and my trusty debugger. Using 2 monitors, starting at main() or index.php (or whatever of course), I will execute as much of the entire codebase as possible line-by-line. At first I will blast through the code looking at general structures and entry/exit branches and the like, and note things and often breakpoint sections that seem hairy or where I can note inefficiencies or great design. Then I slow down the stepping and really examine the heavy-lifting sections to try to become familiar with the style and abstractions being used. This method has served me well, as more often then not, by the first day's afternoon I can be having intelligent conversations with the existing team, almost always much to their confused surprised. I suppose it matters much if you are going into the senior position as really strong head-down coder or as really more of a project management liaison. Not being much into the management side of things, I don't have much advice on that role, and your suggestions sound really smart.
  • mijoharas 9y ago
    What does IC stand for?
    • Chickenality 9y ago
      Individual Contributor
    • deleted 9y ago
      [deleted]
    • xyzzy_plugh 9y ago
      Individual contributor; i.e. not a pointy haired boss.
    • cubano 9y ago
      Independent Contractor
• dxbydt 9y ago
  This is a bad idea. Definitely well intentioned, but has a lot of bad side effects. Especially at big companies, I was instead actively encouraged to dive right in, make very small changes to existing production code & submit it for a code review. That gets you started in the right direction asap, because the feedback is direct - its pertinent to your code that you wrote, so you feel it viscerally & begin understanding the code even though 10 minutes back it was an opaque mudball. If you become a waterboy, you will definitely be appreciated by the team, productivity & morale will go up etc - But you personally didn't sign up to be a waterboy! You came to be a player. So play. You can't go from being a standup-summarizer or infra-support-guy to your regular senior developer role. If you are any good at those ancillary roles, you will be playing those roles for a long time. Every day doing infra is a day not doing regular dev - that's just the way it is. I have been there & its not fun. These ancillary roles have a way or morphing into a fulltime job, and soon that's what you'll end up doing. This isn't WMA/CAA where you start in the mailroom and few years later you become Hollywood's top producer greenlighting 100 million $ movies. It simply doesn't work like this in tech companies.
  • JackFr 9y ago
    I think the parent was the lead taking the onus off his direct reports. In such a case, improving your team morale and productivity is more important than closing out a couple of 1 point stories. On the other hand, if the team were peers in the org chart, I agree with you.
• lmilcin 9y ago
  As a senior dev my role is to stay away from doing those tasks as much as possible. Well functioning organizations do not keep senior devs to do the stuff that junior devs can. My first task at a new team is to have a 1:1 with my manager to set our relationship properly and this includes laying out all expectations. Typically managers understand that it takes some time to get productive. Do not waste that time by doing tasks that do not increase your productivity. You should be learning the codebase, the development process, etc. Fixing bugs is one way to do it, but not necessarily the best. You may easily spend a lot of time on this, not gain much insight and actually not make a good impression as your colleague with much more experience will do it in 1/10th of the time. Also, starting on the right foot with the team is also important for your future productivity so it may be necessary to do some of those tasks anyway, but always remember that at the beginning your job is to build a good base for your future work.
  • grogenaut 9y ago
    I'd agree with this but I also do 1:1s with the rest of the engineers on at least a monthly basis. They use it as a sounding board, career advice, or general design meetings. The don't often happen but it gets them in the practice of talking to you over issues and other things. It also gets you a lot of insight into their thought processes and general issues of the team. I find this works better than just reviewing every single commit and commenting on them, it lets you get into the meta more. And it gets you there before the code is written so it removes the "but it's real close can't I just push" drive most devs have.