Live data from Hacker News

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

news.ycombinator.com

151–160 of 186 posts

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

#151
post #136
post #71

Earlier quoted context omitted.

Sorry, an hour a day doing busywork (like entering hours) in a startup is utterly indefensible. I've done a bunch of startups and not only did this never happen, it would not have been tolerated. Even at > I never spent more than about ten minutes a day doing tracking; during heavy bug crunches, maybe an hour doing detailed writeups within bugs for other groups, for communication purposes. In a small team in a compan…

> Time tracking by the hour... How is that a difficult idea to get around? As a contractor I'm expected to keep track of my hours and what I'm working on. Lucky it's just a chrome extension that I click to start and click to stop. Boom, tracking by hour of what I work on.

It's not a difficult idea. Mindfulness of how you are spending your time is quite useful.

What results from it is, however, difficult. Nearly without fail I have seen these tracking systems degenerate into blaming, micro-management and tools for destruction ("Figby is working two hours a day more than you are, what's up?")

So no, not difficult at all. Easy to do. Much, much harder unless you want a culture of fear and overwork in your company, and screw that, I've been there.

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

#153
post #143

First thing is first, you are learning a new stack, you probably have coworkers that know it better than you, so you have a golden opportunity to kill two birds (gain favor w coworkers & learn fast) with one stone! Do not bother your coworkers with endless questions or interruptions, but try to use scheduled times to discuss how you're going to build things. In an ideal company, you shouldn't be building things in a…

Very interesting insights, thanks.

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

#154
post #16

I'm a little confused by both the question and the current answers. Maybe because, when I've had that position, there was a project manager that or similar that dictated what should I do and what was expected from me. Also being new with a tech stack is enough of a handicap to keep me busy getting to speed, so adding quality and better engineering practices had to wait. Actually, the first time that I found myself in…

True. Learning the framework and its idiomatic style is very important.

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

#155

The other replies here are misguided. A senior developer's job is not to take over as a know-it-all dictator at the end of their first week. You don't write unit tests for existing code, refactor other developers' work, take over the role of architect or sysadmin, make sweeping changes to existing processes, or take any other "heroic action". The number of comments here essentially saying "assert your dominance by in…

Your view is quite different from the others​. But very insightful.

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

#156

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

There is no such official role in my organization. But the expectation from me, owing to my experience, is to ramp up fast and lead the engineering aspects of the team.

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

#157
post #82

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.

I sometimes do this with code that nobody understands but generally you should first talk to the people already there and understand the code.

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)

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

#158

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.

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)

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

#159
When you say "be productive," whose judgement will be making that assessment?

I ask because if you were hired to come in and right the ship, writing tests might not be perceived by your manager as the right thing to do. If you need to impress the other developers, that might or might not be the right choice.

If you are trying to communicate progress upward, then I would make an honest assessment of the challenges and write down a plan for your manager.

If you are trying to impress downward, then that's probably a cultural challenge and you can figure out what to do from the comments here.

It really depends who cares about your progress.

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

#160
As always, it depends on the context.

Do you know why you were hired? You mentioned "10 devs, QA, BA" .. maybe a good chance to talk to everyone and write down and later agree on a roles & responsibilities matrix. Same goes with process. Talk to everyone and find out what they actually do, write it down and then have an objective discussion if all this is still the best way of doing things / working together.

As for the coding side of things: using cloc [1] and cpd [2] proved to be super helpful every single time for me. When talking to current devs you are likely to get a glimpse if what they worked on recently or will work on in the next few weeks. Cloc gives you the whole story from the beginning. Maybe it's a new stack -- but how come there are 1000s of lines of perl code in the repo? Always a joy to dig deeper and learn about the history. Cpd is a great helper to gauge what your devs actually do vs. what the say. In the heat of deadlines it is often the case that stuff just gets copy and pasted rather than refactored -- which will turn into a nightmare sooner or later. Bonus points for lots of copy/pasting in your test suites and automating cloc & cpd runs ..

Also, if everyone is busy adding code/features, be the one who removes stuff that isn't needed anymore.

On the learning side: you said you are not familiar with the stack. Are you sure your team is? This is a great opportunity to start a learning/ book reading activity for your team.

Last but not least, always assume best intentions. A lot of things probably do not make sense anymore but they did in the past -- find out about the history and you'll earn the trust required to make an impact in the future.

[1] http://cloc.sourceforge.net and https://github.com/AlDanial/cloc [2] http://pmd.sourceforge.net/pmd-4.3.0/cpd.html

Post reply on HN