Live data from Hacker News

Ask HN: How do you become productive in a new project as a senior developer?

news.ycombinator.com

61–70 of 186 posts

Re: Ask HN: How do you become productive in a new project as a senior developer?

#61

> My guys were time reporting into 3 different tools (and this is a Who is the fscking idiot that calls himself a startup founder and makes people report in 3 different tools?

This kind of attitude is really unhelpful. Of course this sort of situation is undesirable, demonstrably, but it's not necessarily a case of idiocy - it's actually very easy for non-technical founders to get into this situation: let's say the developers want to use JIRA, but the non-technical staff find JIRA impossible to use (totally reasonable), so they want to carry on using Trello; straight away you've got tasks…

Although it is understandable how someone could make this mistake, mandating redundant reporting is a very bad sign in a startup. It shows the manager does not comprehend the difference between a giant company where such large overheads are necessary, and a tiny startup where nimbleness and intimacy and the very thing that gives the company a chance to succeed.

Re: Ask HN: How do you become productive in a new project as a senior developer?

#62

> My guys were time reporting into 3 different tools (and this is a Who is the fscking idiot that calls himself a startup founder and makes people report in 3 different tools?

This kind of attitude is really unhelpful. Of course this sort of situation is undesirable, demonstrably, but it's not necessarily a case of idiocy - it's actually very easy for non-technical founders to get into this situation: let's say the developers want to use JIRA, but the non-technical staff find JIRA impossible to use (totally reasonable), so they want to carry on using Trello; straight away you've got tasks…

>time-tracking by the hour is incredibly important

As someone who does the R&D tax credit for a lot of tech companies, let me tell you that it really, really is. It's worth somewhere around 10% of all your developers' salaries if the company is profitable. As in, if they work 10 hour days, entering data into a time tracking system is a net benefit even if it takes up to an hour a day.

Re: Ask HN: How do you become productive in a new project as a senior developer?

#63
post #4

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 free up your devs from distraction and pointless tasks. Productivity and morale will immediately go up. My guys were time reporting into 3 different tools (and this is a <10 person startup!), I just started writing a summary of our standups and told them they…

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.

Re: Ask HN: How do you become productive in a new project as a senior developer?

#64
post #62

Earlier quoted context omitted.

This kind of attitude is really unhelpful. Of course this sort of situation is undesirable, demonstrably, but it's not necessarily a case of idiocy - it's actually very easy for non-technical founders to get into this situation: let's say the developers want to use JIRA, but the non-technical staff find JIRA impossible to use (totally reasonable), so they want to carry on using Trello; straight away you've got tasks…

>time-tracking by the hour is incredibly important As someone who does the R&D tax credit for a lot of tech companies, let me tell you that it really, really is. It's worth somewhere around 10% of all your developers' salaries if the company is profitable. As in, if they work 10 hour days, entering data into a time tracking system is a net benefit even if it takes up to an hour a day.

Thanks for that insight. I didn't realize that existed.

Re: Ask HN: How do you become productive in a new project as a senior developer?

#65
I'm similarly one month into a new senior development role. Although I am familiar with the tech stack, the system's functionality, deployment environment, and points of interface with other systems are fairly complex. The other devs on the team will answer specific questions but are pretty stingy with their time when it comes to something like an overview of the system. I could (and have) read through a fair amount of the code, but IMO, that is very inefficient and potentially misleading way (you might be able to see what is happening but not necessarily why, something that is important for senior devs to understand) to come up to speed on it. Oddly enough, the organization has a very structured onboarding process for everything except coming up to speed on the specific details of their product's functionality. Frankly, learning everything about their expense reimbursement policy and the health insurance website by day two is nice, but not nearly as useful as coming up to speed on how their product works. I'm finding it pretty frustrating.

Both here and in previous roles, I start with the data model and work my way backwards. If you don't understand the data, it's nearly impossible to understand what the system does. In previous roles, I'd also browse through the production environment (e.g., AWS) and look at the monitoring pages for the different components (databases, EC2/ECS instances, queues, etc.) in order to get both a sense of the topology of the production environment and where bottlenecks might exist. In previous roles, I've been able to make some significant improvements early on as a result of that. In my current role, utilization is Earlier in my career, I had a team lead who hired me into a role on a complex system and he scheduled one hour per day with me for a full month to walk through various aspects of the system. Obviously that was a pretty significant time commitment, but I think it paid off for him in that I came up to speed pretty quickly and was quite productive. That always stuck with me and when I became a team lead, I always budgeted a significant amount of my time to bring new members of my team up to speed. I'm pretty frustrated in my current situation as an unproductive senior developer due to unfamiliarity with the functionality of the system and confused as to how its beneficial to the company to operate this way since I am rather well-compensated. I think it's quite penny-wise and pound-foolish for organizations to hire developers and invest as little time as possible in bringing them up to speed.

Re: Ask HN: How do you become productive in a new project as a senior developer?

#66
post #25

Earlier quoted context omitted.

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…

Keeping management informed via daily email does not scale. Nor via phone or meetings. All this daily distraction nonsense. Have a high-overview webpage where they can look it up by themselves if they need to. This is faster than daily and gives much better and accurate info. It's your task to communicate the metrics, scheduling problems, cost overruns and feature creep.

S

Re: Ask HN: How do you become productive in a new project as a senior developer?

#67
Your team, especially if their morale is subpar, is your number one asset. Code and deadlines will come and go, but the team, or the lack there of, is (in reality) all you have.

If you're not actively engaging them for input, insights, etc. then you could be short term smart and long term foolish.

Even as a serious dev you're still 75% manager, and, at best, 25% leader. Your duty is to put your people into a position to succeed. And until you know it all (sarcasm), they're going to have thoughts and feelings on what that future looks like.

Re: Ask HN: How do you become productive in a new project as a senior developer?

#68
post #4

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 free up your devs from distraction and pointless tasks. Productivity and morale will immediately go up. My guys were time reporting into 3 different tools (and this is a <10 person startup!), I just started writing a summary of our standups and told them they…

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.

From experience, I find that I'm not really able to add meaningful tests until I have an idea of what's going on.

Re: Ask HN: How do you become productive in a new project as a senior developer?

#69
post #4

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 free up your devs from distraction and pointless tasks. Productivity and morale will immediately go up. My guys were time reporting into 3 different tools (and this is a <10 person startup!), I just started writing a summary of our standups and told them they…

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.

Re: Ask HN: How do you become productive in a new project as a senior developer?

#70
post #4

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 free up your devs from distraction and pointless tasks. Productivity and morale will immediately go up. My guys were time reporting into 3 different tools (and this is a <10 person startup!), I just started writing a summary of our standups and told them they…

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.

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.

Post reply on HN