Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 186 posts

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

#91

Post by sabelo »

bollockitis wrote: post #54
Jedi72 wrote: 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 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.

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

#93

Post by daveguy »

gjjrfcbugxbhf wrote: post #75
WrtCdEvrydy wrote: post #63

Earlier quoted context omitted.

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.

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.

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.

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

#95

Post by stult »

raverbashing wrote: post #84
stult wrote: post #62

Earlier quoted context omitted.

>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.

What kind of tracking do you need and what's the needed resolution? Can we just have "customer work" or "R&D work" for 8h a day?

The quality of your data dictates the probability of getting an accurate, audit defensible credit calculated. More detail makes it easier to defend. We can work with "R&D work" level of detail, but it is less defensible and it will cost more to have us (an accounting or consulting firm) calculate the credit for you. It also makes it much harder to calculate in-house or using paid self-help software tools.

Particularly because IRS rules require that the wage costs be allocable to a "business component." Business component is a technical term of art specific to the R&D credit, but roughly it corresponds to projects, and more specifically to a (1) new or improved (2) product, process, technique, formula, or invention. It must be one and only one of those, no mixing of new and improved or product and process. So if you have a new product and a corresponding new production process, they must be separated in the reporting of qualified research expenditures, even if you as a taxpayer have classified the two BCs as a single project.

So when you have time tracking, it is best when it allows us to tie specific hours worked to specific projects and tasks. We can then work out from the project list how to combine or split up your projects into business components and map the costs that way. From your activity codes, we can set a very specific and defensible qualified percentage to each employee's time, without having to disrupt your business by surveying your employees (plus the IRS does not respect self-reported, non-contemporaneous survey data much if at all).

As an example, I walked into a software dev client's offices a few weeks ago to sit down with the CFO, comptroller, and their head of development. I walked out with highly detailed project tracking data and spent four hours processing it using our internal software tools, calculating a $2m benefit with a high degree of accuracy. At other firms with lower quality data, it can take hundreds of man hours to achieve the same benefit. So we gave the software client a massive break on our fee (and actually still profited more than we would have with a less prepared client) and everyone walked away happy.

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

#96

Post by emodendroket »

noway421 wrote: post #14

I think it is a little bit of exaggeration to claim Senior Developer title on a project with unfamiliar tech stack.

To the contrary, I'd say the ability to pick up a product in an unfamiliar tech stack and be productive relatively quickly is one factor that would make you more deserving of the "senior" qualification.

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

#97

Post by stult »

ljw1001 wrote: post #83
stult wrote: post #62

Earlier quoted context omitted.

>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.

I think that you're not necessarily considering the side effects of (A) working 10 hour days, and (B) spending an hour on paperwork. People will often start to wonder why they work so hard if the company doesn't take their time seriously. This can negatively impact morale, and that has a real, if hidden, cost.

I picked those numbers to make the math easy. No one should or will spend anywhere near an hour entering time into a time tracking system, unless it is horribly designed.

>People will often start to wonder why they work so hard if the company doesn't take their time seriously.

This is a failure of communication. People tend to get frustrated with paperwork when they do not understand its purpose or importance. Those employees who are discouraged by hours tracking paperwork don't realize that the company is being paid by the government to have them fill out that paperwork. Management needs to communicate to employees that there is a very significant impact on the bottom line from them properly filling out that paperwork. That impact increases their wages and the company's ability to survive and thus to provide them continuing, stable employment.

Now, if you think its pointless that the IRS requires them to fill out this paperwork, well that's another discussion, but I can offer you arguments in favor of verifying R&D activities before granting public subsidies for them and in favor of the subsidies themselves.

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

#98

Post by raverbashing »

stult wrote: post #95
raverbashing wrote: post #84

Earlier quoted context omitted.

What kind of tracking do you need and what's the needed resolution? Can we just have "customer work" or "R&D work" for 8h a day?

The quality of your data dictates the probability of getting an accurate, audit defensible credit calculated. More detail makes it easier to defend. We can work with "R&D work" level of detail, but it is less defensible and it will cost more to have us (an accounting or consulting firm) calculate the credit for you. It also makes it much harder to calculate in-house or using paid self-help software tools. Particularl…

Ah I see. But task tracking != project tracking

And this does not necessarily require everything to be done by the developer

Even if the value that can be obtained by this is higher, it seems to me it's cheaper (in general) to have someone track the effort in this specific way than make developers do it. (Also if your developers are unhappy or busy no tax credit can save you)

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

#99

Post by davnicwil »

phd514 wrote: post #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…

> I'm pretty frustrated ... and confused as to how its beneficial to the company to operate this way

It's very likely not a considered strategy; rather the total opposite. Technical managers and by extension teams are, generally, really bad at onboarding.

It's nobody's fault per-se, just an unfortunate artefact of giving people responsibility for something they never trained for, usually without any formal plan, and expecting them to just figure it out on instinct.

Of course, most don't. Some do though, really well, and if you find one you've found a gem! It's unfortunately not the norm. Don't frustrate yourself thinking that it is.

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

#100

Post by rb808 »

I think most of the replies are solely technical. Sure that is important, but I'd say you need to also spend time with users, customers, management, marketing etc to find out what they want out of the system. Also HR issues - can you hire & fire people? Get money for resources? Bring in new tools?

Its often easy to dig into the code as that is familiar but that probably wont be what you'll be judged on down the track.

Post reply on HN