Ask HN: How do you become productive in a new project as a senior developer?
Additionally, the project is on a new tech stack (for me). I would like to be productive as soon as possible and help the team move faster while adding quality and better engineering practices.
Any tips, help, books? Thanks.
185 comments
[ 2.1 ms ] story [ 215 ms ] threadIt will help you to learn the system and technology better than any documentation will. Also it keeps you of the way of the other developers who frankly have better things to do than babysit you (just being honest) but also gives you regular opportunities to chat with everyone as you work through different issues.
Either that or improve monitoring/supportability. Gives you an opportunity to build relationships and earn brownie points with your DevOps/SysAdmins.
Apart from that, I can only recommend to play with the tech stack in a throw-away prototype before using it for real, because the first decisions you make in a project tend to be those that are hardest to change later on.
Approach the task with humility. First observe, participate and learn, then come up with improved practices.
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 didnt have to do it individually any more, it was appreciated and mgmt still get the info they need. 2) Start with infrastructure stuff - how do you deploy, what's your build process, can anyone on the team draw an architecture diagram (mine couldn't) 3) Write tests, it's low risk changes to the codebase so you cant really break anything, but it'll give you the black box overview of how everything hangs together, detail will come in time 4) Accept that there's no way to immediately get to the level of familiarity the guys who built the system will have. I can spend 2 hours digging trying to find how widget x gets its props passed in, or I can ask my teammate who wrote it and immediately known which file and line its on.
Burp has a broader scope because it does fuzz-style random testing. Zap is more reproducible. (Burp can be a pain in the neck because it doesn't reliably retest stuff it found.)
Be gentle with your new developer colleagues as you present them the results from these tools. They almost always find a couple of more-or-less silly vulnerabilities.
I'm skeptical that management would need a daily status.
They really have no idea what they're doing.
How are these deadlines getting set?
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 QA is on top of testing hot new changes that need to be rolled out ASAP. Daily isn't frequent enough in this context.
Burning through the QA backlog leading up to a big release in ye olde milestone driven waterfall style schedule? Daily might be frequent enough.
Long term feature work? Might be able to go weeks between updates - but a daily ping of "still working on X, still on schedule" takes what - 5 seconds to email, 5 seconds to read? Helps keep the mental burden of juggling everything in your manager's head down, maybe helps reassure them you're not going to pull a "so yeah, we've still got a month of work left at least" on delivery day when they're reporting up to their management. They might not be able to help you get your task done faster, but they might be able to rearrange other parts of the schedule to keep their stakeholders happy (e.g. X is running into delays, but we can give you Y ahead of schedule). Even if they can't do anything to help the schedule, they can start managing expectations ahead of time, prevent unseemly "surprises."
And hey, daily status reports are better than daily status queries.
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.
The thing is, it's all about visibility. Can management look at your sprint board, either physical or online, jira agile board for example, or in some other tool, where they can see what's going on? That's a good place to start.
Who keeps this up to date and well maintained? I see little fundamental difference between pushing metrics/status via JIRA and pushing via email. Both scale (or don't) just as badly. Both require distraction from your development tasks to properly estimate or summarize status/problems.
Don't get me wrong - keep the daily distraction the hell in check. But there's no magic bullet to make good communication free, and there are plenty of people and contexts where words and language work way better than attempting to abstract things with stats and metrics.
> This is faster than daily and gives much better and accurate info.
Maybe for you. Maybe for me. Definitely not for a lot of coworkers I've known. They do not context switch from "this is harder than I thought" to "track down the JIRA task and change my estimates". Getting some of them to even log work done is like pulling teeth. Hence hacks like the daily standup - poll, use words, get the real status.
Plus of course improving the infrastructure. This is also mostly in the same poor shape as the docs.
Of course you can ask people who are more familiar but whether you end up helping or being a distraction then is an open question.
Ask on your team's IRC channel.
Benefits:
(1) You only really need to know the system as a user, not the codebase as well, to do this.
(2) Well, #1 was a bit of a white lie. You'll end up finding out about all the (possibly undocumented) runtime dependencies this way, spinning up throwaway VMs and databases, etc. If the project is in production, this will be very useful knowledge, since you're probably the last point of escalation for strange prod issues.
(3) Running this out of CI with throwaway VMs/containers will also force you to fully automate the install and make the damn thing actually work on a generic blessed OS configuration, which might be a huge boon to your team if you currently are in "Works on my machine" hell. I did this somewhere where we had tons of lost productivity because developers used OSX or Ubuntu on their workstations, but prod was RHEL, and the most fascinating deviations would be found by developers chasing the strangest of bugs. Making the install reproducible so we could have CI totally ended this.
(4) If you don't have this already, and you set up infrastructure to gate commits on this test passing, team love and productivity will rapidly go through the roof as suddenly your developers aren't spending half their time fighting each other's build breaking changes.
So yeah, it's just one thing, but it leads to so many benefits it's definitely where I would start.
EDITED: Added an item to the list
* 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.
Seriously, the most useful thing I've ever done is just refactoring half of a project to see how it works.
This is a good way to cut the velocity of whole project so you don't look as lost though.
Nah, I usually just do a feature branch, refactor items with better stuff and we can then cherry-pick anything that's sexy and still fits our business needs once we've talked it over.
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.
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 first I will blast through the code looking at general structures and entry/exit branches and the like, and note things and often breakpoint sections that seem hairy or where I can note inefficiencies or great design.
Then I slow down the stepping and really examine the heavy-lifting sections to try to become familiar with the style and abstractions being used.
This method has served me well, as more often then not, by the first day's afternoon I can be having intelligent conversations with the existing team, almost always much to their confused surprised.
I suppose it matters much if you are going into the senior position as really strong head-down coder or as really more of a project management liaison.
Not being much into the management side of things, I don't have much advice on that role, and your suggestions sound really smart.
Pretty sure it's because they assumed IC was Individual Contributor but to downvote the "least common answer" is weird seeing as how, in this case, it's the source...
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 and start working on them, and then slowly moving up in complexity.
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 how/why it doesn't work, trying a new one - suddenly I get it.
Everyone's different.
If you become a waterboy, you will definitely be appreciated by the team, productivity & morale will go up etc - But you personally didn't sign up to be a waterboy! You came to be a player. So play.
You can't go from being a standup-summarizer or infra-support-guy to your regular senior developer role. If you are any good at those ancillary roles, you will be playing those roles for a long time. Every day doing infra is a day not doing regular dev - that's just the way it is. I have been there & its not fun. These ancillary roles have a way or morphing into a fulltime job, and soon that's what you'll end up doing.
This isn't WMA/CAA where you start in the mailroom and few years later you become Hollywood's top producer greenlighting 100 million $ movies. It simply doesn't work like this in tech companies.
On the other hand, if the team were peers in the org chart, I agree with you.
I'd take the time to ask each member of the team, what they are working on, what problems they are having, and how you can assist them in some way.
The product your company/team is building will have a roadmap of features to be delivered, spend time with members of the Dev team talking through each of those features, what is required, how they plan to build them.
As a senior, you may not know the platform, but you can get to know how the team works, offer suggestions and identify probable pain points. There might be entire sections of code you can work out that needs to be written which don't necessarily require knowledge of the platform.
All this will take time, be incredibly useful for everyone and in your spare time you can learn about the platform.
Get the team to whiteboard the architecture with you. This is better than existing documentation because you will get the full commentary and start building a mental model of the software.
Ask the team about problem areas.
Don't push on major stack/architecture changes until you know the stack/architecture.
Make sure the base engineering practices are there. You should have a seamless workflow from pre-merge code reviews, testing, and deploy.
Yes, it's a nice way
You need to exercise skill of being able to do an organised exploration of the codebase, probably producing documentation along the way.
I recently witnessed an instance when a senior develoer heavily relied on others for information as you suggest. The team was failing to deliver the manager was incompetent. This senior developer I hired on with was made a scapegoat and blamed for slowing down the team and causing missed deadlines. This was absurd of course, but she got away with it, and he was fired.
- got a broad overview of the code from my team
- agreed to be the on-call just after two weeks of time; learned a lot because I had to move fast to fix issues (also call people)
- asked the starting point and the core part of the entire codebase (helped me understand code at least 3x faster)
- deployed a feature within 2 weeks of joining
Note: I am not a senior developer, but a software engineer.
I never cared about what stack someone uses.
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 variability across companies, but it's safe to say that "Senior Developer" is never an actually senior position. People holding it are never in charge of big things.
As always, you need to ask questions, not make assumptions.
It might be that I read the question wrong. OP says that the tech stack is unfamiliar, and I guess it comes down on whether they've been familiar with a similar tech stack or something is architecturely different.
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 such a situation, I later regretted I had not invested much more time in learning the framework so I could had detected bad design that later slowed us.
Inform management, and make sure it'll be deployed when you fix it - you want to learn the entire process of development and not just the code.
Start learning the architecture, stack and development process with the goal of fixing that single bug. You don't have to learn the entire stack/architecture to fix that single bug. Try not to refactor the entire system while your fixing a bug - the point is to learn how the system works, not to redesign it.
Make notes of the pain points you have - from setting up a dev environment, to lack of documentation or even communication problems.
When you finish, do another bug, perhaps something more challenging.
If you feel that you need to read a book, or do a tutorial on part of the stack you don't know to fix the bug, then do so.
When your done with a few bugs, you are in a position to know and prioritize what quality and changes could be helpful, try and implement them.
I try to go in with an open mind and assume the developers who went before were at least competent and had good reasons to do things the way they did. Sometimes this charity is unfounded, and the code truly sucks, but usually some poor decisions can make sense when you have more context.
Ultimately, I just dive in and start fixing bugs or implementing features. I'll start with the build to understand what the project actually consists of, then I rely heavily on shell tools like grep and find to explore the code.
I once inherited a fairly large c++ application that could only be built on THE dev box, or a copy of it. Only one old timer understood it, it was his meal ticket, and he wasn't talking. It used auto tools so I converted it to cmake so I could build locally. Then I spent about two weeks just reading the code, started at main() and wrote everything down in an architecture doc on the wiki (file and method level, only document method internals that were really hairy). Then as enhancements or bugs came up I'd flesh out the doc some more.
Another time I inherited an old IE6-7 app that had to be modernized. Besides the MS specific stuff, it was a mess of javascript spaghetti. Again here, I had to figure what files where actually used by the app, so I grepped log files and browser network logs to figure what was actually loaded, and just read the code. The first major project I did was to remove many hundreds of unused files.
I am interested to know what happened to the "old timers" meal ticket?
Along the way, you'll of course need to talk to people to understand both the code that has the bugs and what is expected of it, and you'll learn years of history from both the development side and the product side, which is invaluable.
It's unusual these days that I just grab a feature or a hotfix and knock it out - generally only the ones too big and scary for anyone else to handle, and my guys are good enough that those are pretty rare.
Be aware that to do this in a time-efficient way, you might need to pull in one of the existing engineers who can give you the lay of the land.
Start by having someone on the team give you a brain dump. Record it. It doesn't need to be high quality. Use Quicktime and your laptop's webcam.
After the braindump, write out everything that was said and make the following diagrams:
- Architectural diagram showing the components involved.
- Infrastructure diagram that shows where things run.
- Deployment pipeline that shows how code gets from git commit to production.
- Data flow diagrams for the most common usage patterns. This one might come a bit later as you're more hands on in coding.
Show the diagrams to your team members as you create them and ask them to verify that it's accurate. If it's not, understand why and fix your diagram.
Add the above to your onboarding docs. If none exist, create it somewhere.
Add a page to onboarding docs that describe how to access logs.
Add a page that describes how monitoring in the system works.
Add a page that will act as an index for recipes on how to do useful things. From that page, create a bunch of useful scripts that you gather as you learn stuff daily. Encourage others to do the same.
I think you get the picture. Add a page for everything you need to know in order to be productive. Think about all the things you knew how to do in your previous position. Try to document how to do all those things in your new position.
Soon, before you know it, you'll be productive and you'll enable your team to be able to onboard new team members more efficiently.
In addition, write code and review PRs. Ask a lot of questions in PRs. Investigate how things work. Get curious.
X can be user hashed passwords, server's certificate keys, etc...
If you are the bridge between business and dev, you have to manage business expectations and point what needs to be changed. If you are the technical guidance of the team you have to be on top of code quality and architecture.
In the end, the role name doesn't really mean a thing, it's what is expected of you and your legroom that matters. Both are dynamic. In fact, every team member is free to suggest improvements, how fast they are implemented just depends on who approves them. Senior normally just means you don't need alot of supervision.
Who is the fscking idiot that calls himself a startup founder and makes people report in 3 different tools?
No, what's unhelpful is less than 10 people acting out in an noncohesive way
This is weak management and a lack of focus
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.
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 of science or technology through the resolution of scientific or technological uncertainty - and not simply an advance in its own state of knowledge or capability.
From the gov.uk article:
https://www.gov.uk/guidance/corporation-tax-research-and-dev...
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. Meaning, that uncertainty can be "simply an advance in its own state of knowledge or capability."
Honestly, I shouldn't say this because it's very much against my own interests, but the US regs are way too loose and permit credits for work that just does not seem to me to be worth subsidizing. But for a normal development company, it's worth tracking hours to gain that subsidy because the IRS primarily challenges us on the validity of the underlying data at this point rather than the qualification of the activities themselves, because a large amount of litigation has settled most of the questions in that area in favor of taxpayers.
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.
The standards are pretty loose.
>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.
Can we just have "customer work" or "R&D work" for 8h a day?
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.
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)
Every development shop in Canada claims credits to recoup a significant portion of employees' salaries. Yet not a single one of my companies has ever performed R&D. The analyst comes in and spends a week getting every employee to lie about their work, enticing them to rephrase how their mundane copy-paste-from-Stackoverflow work somehow qualifies as "R&D". The majority of taxpayers' dollars paid to corporations through the SR&ED tax program is fraudulent.
Instead, the tax credit is really a political compromise crafted to appeal to both sides of the political spectrum. It's about subsidizing high paying, professional, white collar, technical jobs so that employers don't outsource them. That makes the credit an anti-free market subsidy designed to protect jobs but disguised as a pro-science, pro-innovation policy whose main beneficiaries are large corporations.
And honestly, even in the most "sciencey" firms, most of the R&D going on is dreadfully repetitive and unimpressive. Just as you cut and paste SO code, pharma researchers are just "cutting and pasting" the nth iteration of a chemical formula. They're not unlocking the secrets of the universe, they're just trying random shit until it works. Which, interestingly, is part of how the tax regs define a process of experimentation. Instead of "trying random shit until it works," the regs call that strategy "a systematic trial and error methodology."
Your issue is that you have a mental definition of R&D but the tax codes of the US and Canada do not define R&D in the same way, which to you seems dishonest. But you need to remember that, from a tax perspective, the definition isn't important except insofar as it helps or hinders the underlying policy objectives. Your definition may be closer to a colloquial or idealized definition of R&D, but it's not necessarily the definition which best achieves the policy objectives of the governments in question.
Either you have people who can do the work and coordinate, or all the tracking in the world is not going to help.
(Time tracking by the hour . . . I can't even . . . it's time to get a new manager by firing the current one or finding a better job elsewhere. Totally serious).
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.
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.
There is, unfortunately, no simple solution other than the very obvious one, which is to use the right things for the right job, and as few of those things as you can. The really crushingly miserable situation is one where the documentation is in Confluence and Google Docs and some random files in Dropbox before they started using the first two and some files that someone shared on the Slack channel and a few things that are just in the CTO's inbox which he was sent by the CEO in PowerPoint and... it's utterly toxic.
This proliferation of excellent tools we have today should be a good thing, but really we are all victims of our own best intentions sometimes (in that horrible chain of misery, even the CEO honestly thinks he's being helpful by emailing a PowerPoint rather than just telling someone over the phone).
This is the thing with the Atlassian ecosystem. Whether you are pro-Atlassian or anti-Atlassian, there are only two sane options: you either all-in with everything Atlassian, or you are better off with nothing Atlassian. Mixing and matching products when Atlassian is involved is the wrong choice, every time.
The Atlassian suite as a whole is fantastic when the integrations are set up properly. If you dislike Atlassian's licensing or even one of their products, then you should not be using them at all. Don't take on 1-2 of their products, and then replace one of their other core products with an unintegrated competitor. Having a partial Atlassian setup is frustrating as hell to work with.
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.
In my opinion, detailed time tracking is pointless. I've worked for companies that required it (only small ones required this), and it was just a painful distraction that never had any perceivable benefit. In larger companies, most people just write 8 hours a day for their project, and that's it. No need to make it any more complex than that.
And Jira is not a reporting tool. It helps you keep track of the work you need to do, and roughly estimate how much work that is, but it's not suitable for detailed reporting. And for a small startup, you don't need detailed reporting. If the boss wants to know what people are doing, he just needs to drop by at the standup meeting.
proceeds to describe idiocy
The bugs give me an overview of the system and let me develop my mental map of the code base, the performance problems give me an overview of what's been done wrong.
Now, take a step back. How easy was this? It should ... must... be absolutely frustration free. If not, fix that.
To come up to speed on the tech stack, go sit with the other developers. Get a feel for how they are using the technology. Then, start picking off some smaller issues from the backlog and try and fix those.
Don't make assumptions. Learn the tech without an opinion. Sure, you won't like some of it (nobody likes everything), but find out if the team likes it. If they do, don't try to change that.
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 <5% on almost everything, so that hasn't been helpful.
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.
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.
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.
Since you're new, you don't necessarily have all the insight to make this happen on your own. So ask your team! "What can I do that would make everyone more efficient."
Also, make it clear that you are available for general questions on technology, architecture, algorithms, secure coding, etc. I spend one to two hours each day fielding questions like this, and I don't have a lot of in-depth knowledge of our code. But all code needs architecture and algorithms and security best practices. And since I don't have to actually spend the time coding, I'm multiplying my capacity to make decisions. It's also great for developer ownership, when I get to say things like, "I can give you general advice, but you know your code the best. So apply it with discresion."
This is an excellent quote and I plan to use it, or a close variant. Thanks very much for sharing!
* read the docs
* document what is not documented
* write tests
* look at small issues/todos and write code for them
Find out what are the black holes (the problems that will pull you in and not let go).
Introduce one improvement to the exsiting processes (automation, documentation e.g. wiki, lunch & learn/brown bag/dev days etc)
Find out what are the black holes (the problems that will pull you in and not let go).
Introduce one improvement to the exsiting processes (automation, documentation e.g. wiki, lunch & learn/brown bag/dev days etc)