121–130 of 186 posts
Earlier quoted context omitted.
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…
What does IC stand for?
Earlier quoted context omitted.
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…
What does IC stand for?
Earlier quoted context omitted.
Every place has its own names for things, but I often see "senior" refer to your interchangeable seniority in the field, not just in the one company/code base. Then for people to grow into "lead" or "principal".
Senior Developer is typically either a junior or intermediate title. In some places, the title progression for technical professionals is (dev, senior dev, staff dev, principal dev, arch, senior arch), meaning Senior is actually a junior title. In other places, the title progression is (dev I, dev II, senior dev, staff dev, senior staff dev, principal), meaning Senior is an intermediate title. There is of course some…
There's an interesting side-effect of this practice if you've got less-experienced devs on the team: it can encourage them to also ask more questions more confidently.
Earlier quoted context omitted.
I'm wondering how widespread claiming "R&D tax credits" actually is. To think that most companies could/would seems preposterous (how many are truly doing something worth of the monicker R&D?) I'm seeing an ecommerce business applying for R&D credit, and that seems absurd, since > Your company can only claim for R&D tax relief if an R&D project seeks to achieve an advance in overall knowledge or capability in a field…
Well I'm in the US, so I can't speak to the UK's regs with much expertise, except insofar as I know most of the world's R&D credits are based on ours. But in the US, most web dev qualifies, including fairly run of the mill ecommerce site. Just judging from what you quote here thought, the US rule is less rigorous. Taxpayers must resolve technological uncertainty just as in the UK, but it's a taxpayer centric test. Me…
I guess that, even if the rules appear to be stricter, in the UK it might de-facto be the same, if HMRC is not contesting many claims.
That means you'll get productive in same way you'd become productive as a junior. Pick up easy tickets and use them to learn to navigate the codebase. Talk to your colleagues and fill in your knowledge gaps. Help others who are having issues. Pick up and address more tickets. Get in the thick of things as quickly as possible.
If the position includes additional roles, such as that of a PM, nail down the necessary role requirements and start doing those as well. You'll need to work on your soft skills - honey and vinegar, carrot and stick, etc.
You're a senior developer because of your experience and knowledge in general, not because you're magically a productivity machine. Assumptions are going to be your biggest hinderance when coming in to your first "senior" position. Don't assume that you know more than your peers, even the junior ones; when you first start they probably know more about the codebase and tech stack than you do. Don't assume that if a team works differently than what you're used to, it's automatically worse. Don't assume that their code quality and engineering practices are poor.
Don't assume; find the reality and work with your team from there.
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.
1. Build on my machine
2. Reproduce issues
3. Fix bugs -- even typos or refactors
4. See the fix code review/merging/deployment to qa/dev/whatever
When I start a new project I'm most concerned with reproducibility of the process of development. A lot of time other people are blind to the little tweaks that have occurred over the years that enable them to build, test, and deploy a system.
Those tweaks often give a lot of insight into what is going on. The ability to push-button deploy is also a bellwether of what is to come.
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…
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.
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.