161–170 of 186 posts
Earlier quoted context omitted.
An aside, but working 10-hour days is bad. Anything more than 40 hours/week and you're actually reducing overall output.
What if you're working four days a week?
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…
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 f…
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.
Earlier quoted context omitted.
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)
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…
I am at a 13 person startup. We use Confluence, Bitbucket, Google Apps, and we also use Asana (instead of Jira). It is a nightmare... Information is spread out all over these platforms. We can't stick to only Atlassian tools because the CEO thinks they don't allow you to collaborate... We spend a lot of time looking for where information lives and debating where it should live, complete waste of time. In a smaller co…
Similar with Bitbucket. Auto issue transitions means the devs don't have to muck around in JIRA as much. As soon as they start working on a branch (with one click in JIRA) the issue automatically transitions to the in progress column on the board, etc etc.
Reveal: I work for Atlassian and I work using Atlassian tools daily. Asana is a great tool but JIRA is built to help address the issues you are seeing. JIRA functions like a center of gravity to organize your work and many other tools (e.g. ~1000 integrations in the Marketplace connect into it.) We are working on some similar integrations for Trello and have shipped a few already.
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…
Earlier quoted context omitted.
I've tried a similar approach in the past and it just does not work for me. Besides the fact that it is very tedious, I don't retain any of the knowledge because it's like reading a dictionary. It's impossible to absorb that much information, for me at least. My approach to learning a new codebase has always been to do a general overview of the structure while taking notes. Then just assign myself some easier bugs an…
I recently joined a company as a senior developer with a partially unfamiliar stack, and it's very interesting to me how much my style of learning contrasts with others in that way. I regularly am recommended to "read through all the docs, step through all the code", which might work for some. My brain just wants to switch off whenever I do that. Instead a day or two of fixing problems - implementing a fix, seeing ho…
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…
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 doi…
Earlier quoted context omitted.
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.
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.