Manager is asking me to bring in best practices to help with my growth
Posted by galwayygal@reddit | ExperiencedDevs | View on Reddit | 35 comments
I’m a senior dev with 9 YOE. I’ve had a growth chat with my manager and he suggested that I bring forth a best practices doc and a presentation to present to the whole company to help me gain some recognition across the org. He wants me to come up with best practices in a topic (let’s say domain driven design) which I haven’t done before. There’s a project coming up where we’ll be doing some DDD and this is kind of in preparation for that project too. But, in order to write best practices, we should actively work on it, try things that succeed or fail, right? I’ve been postponing doing this until I’ve gained this context. But my manager asked me about my progress on this doc and he seems disappointed that I don’t have a working doc yet on it even though I told him what’s holding me back. Am I approaching this the wrong way?
drnullpointer@reddit
I think your manager sees potential in you but he doesn't know how change is done.
Change is not done by creating "best practices" document that will contain everything and a kitchen sink. I have seen this, it does not work.
This is what I am typically trying to do to achieve a change:
1) Identify a basic statement of goals. Basically, identify a problem that you are trying to solve. This is essential for any project. However vague the goals are, you always want to be doing things towards a goal and measured towards achieving that goal. For example, the goal might be something like improving development velocity or application reliability.
1.1) You probably want to measure your progress towards the goal somehow.
2) Identify or create the tools to make the change. For example, if you have to beg your coworkers to do things differently, that probably will not result in a realistic change. Putting a standards document on a company Confluence rarely results in anything happening. You need to know how the change is going to be actually implement, for example how will you get from telling your team you want them to be doing DDD to a state where they *actually* do DDD. For example, will there be a quality gate at design/code review time?
3) Large change is done typically with a lots of small individual changes. Identify how you can logically get from where you are now to where you want to be. Identify the costs and benefits of each individual project. Identify dependencies (logical order of implementation). Try to start with tasks that have highest RoI.
4) What people do not frequently mention is how to maintain stamina over long period of time. What if management loses patience waiting for their functional requirements to be delivered? What if your coworkers decide that you are going nowhere and therefore working with you wastes time? What you need is a credit of trust that is built and replenished by a constant stream of successes. Simply put, I try to resolve important problems for my bosses, peers and my team. This helps maintain belief that more is to come.
Derek-Gusoff@reddit
You're being asked to show some leadership and influence the future development of the company's tech practices. Your manager is probably being asked from above to have someone do this research.
Yes, and make sure to call this out in the presentation.
This is an opportunity for you to take on some next-level ownership and show readiness to jump to the next level - if you're up to it.
galwayygal@reddit (OP)
Thanks for that perspective. I’m definitely up for it. Just having some doubts about my ability to actually figure out best practices without having the knowledge. I’ll do some research and reading today
Connect_Detail98@reddit
Ask your manager if it's OK to point out during the presentation that you don't have hands on experience on the subject, that this is a product of research into best practices to try to have a solid ground when this project begins. That the presentation isn't just about teaching the company about the best practices you researched but also about taking concerns, questions and feedback that maybe you hadn't considered so that you can go back to the research room and get an even better grasp on the subject.
Trying to solve this challenge in a positive way could help you.
If he says no, then he just wants you to bullshit people... So just bullshit people. If someone asks something you don't know, say it is a good question. Tell them that you don't have an exact answer but you'll get back to them on a DM. That's the best a bullshitter who can't lie can do IMO.
Gondorrah@reddit
Do a prototype with DDD so you gain some experience
pablosus86@reddit
You've said in a few comments that you doubt your ability - if you're being handed this opportunity then you probably know more than you think. Do a little research to make sure you aren't wildly offbase somewhere, write down how think it should be done, and go kick some butt becoming the company's SME! You got this.
FatefulDonkey@reddit
You have 9 years of experience and can't do a simple document outlining TDD practices? In an era of AI?
rupayanc@reddit
"bring in best practices" is one of those requests that sounds reasonable until you actually try it. best practices from where? the things that work at a 50 person startup can actively hurt you at a 500 person org with different constraints. the move that actually worked for me was picking one concrete thing (we started doing lightweight architecture decision records) and letting the results make the case. trying to import a whole framework of practices from a blog post is how you end up with ceremony nobody understands.
LogicRaven_@reddit
They are encouraging you to take an active, leading role. DDD is an example, but your manager likely would support other ideas as well.
What about AI usage best practices and workflows? Or DORA metrics, TDD, test automation and CI/CD, feature flags and A/B testing, etc.
You know the state of the platform and processes, pick something that would bring significant improvements.
galwayygal@reddit (OP)
I’ve actually led some initiatives before to do best practices on AI adoption, e2e tests, data migrations, and good SDLC guidelines. I found this one a bit difficult since I didn’t take the initiative on it myself
LogicRaven_@reddit
If you led other initiatives, why does he asks you to do more.
Maybe your previous work is visible only in the tech team. Or the results were not comunicated.
I would suggest that you talk again to your manager. Focus on understanding the overall goal, not DDD specifically. You could ask what should you do differently compared to to the previous work you led.
Maybe you need to work more across functional boundaries, be more visible or do more research.
pwd-ls@reddit
To diverge slightly from other comments - even with research, if you’re going to present it should probably be something you actually know about, care about, use regularly enough to have found the cracks.
I present with some regularity at my org and it’s usually some pattern, technique, or best practice that I’m passionate about, have tried on different use-cases, and genuinely recommend.
ninetofivedev@reddit
This is a dead end opportunity. Best practices is such a catch all, it's a completely meaningless conversation.
One man's best practices is another man's anti-pattern. Furthermore, any engineer who bases their argument around "best practices" doesn't have a more concrete point to argue from.
Wonderful-Habit-139@reddit
There are definitely things that can be leveraged to make a codebase better. Leveraging a good type system, encoding business logic and invariants using types to make sure that illegal states cannot be represented.
Leveraging tests to ensure that APIs that you expose and promise to not break, keep working.
Your name sounds familiar. I can see why you're fine with AI slop if this is your take. Not surprising to be honest.
ninetofivedev@reddit
I think you really had to try hard to shoehorn that last remark in there.
Let me expand on my talking points because apparently 4 sentences isn't enough.
Whenever an engineer justifies a decision with best practice, it's because they either can't explain their own reasoning for the decision, or they don't actually have anything more to say than they would prefer to do it this way.
TLDR: A lot of junior engineers use "best practice" as a way to justify decisions, because they can't actually quantify the benefits of their decisions. Most senior engineers will let base their arguments on merit.
Wonderful-Habit-139@reddit
No it's because I just remembered your complaints about people that think that they're above AI when they say AI code is low quality. So if this is your opinion, it makes sense why you don't have issues with low quality AI code.
Not saying I completely disagree with what you said, I know you definitely had to deal with arrogant people that overestimate their abilities throughout your career. So I'm not trying to come at you in bad faith.
With that out of the way... Yes, justifying things by saying it's "best practice" is wrong. But besides that, you really don't see for example the benefit of Typescript versus JavaScript? You really think people say that Typescript is better than JavaScript purely because it's best practice?
I don't know know why all of a sudden you're talking about juniors when the post is about a 9 yoe senior. Sure, maybe he should know better at this point in time and be able to figure out various practices that he might have been following throughout his years, but I don't think we're trying to use "best practice" as a justification, but rather as the actual topic that the manager wants OP to explore.
shifty_lifty_doodah@reddit
It’s BS but you can still learn something from it
These sorts of documents need to be inspired by actual need and genuine deep expertise and credibility.
But writing and entertaining/influencing people is a skill in itself, and it improves through practice, so if you practice it you will improve. Most likely no one will care at all. Smart people already have their own opinions and research on this topic
Mephiz@reddit
As a senior, with 9 years of experience, your manager is asking you to shape future development.
You are not the first person discovering or documenting DDD and you should be in a perfect position to research this and make _informed decisions_ and then present to your team.
Wassa76@reddit
Yeah he's asking you to essentially research and make decisions about how you should implement a project.
Maybe propose some ADRs based on your research and invite your team(s) to comment and contribute.
I don't see how this is a problem.
Especially in the world of AI, this is an easy-win and he's given you a great opportunity to gain visibility on a silver plate.
galwayygal@reddit (OP)
Yeah that’s true. It’s not really a problem, but I was having doubts about my ability to present something like that to a big team of experienced devs without having experience myself
chuch1234@reddit
This is how you get that experience \^_\^
Craig_Federighi@reddit
How big is your company?
galwayygal@reddit (OP)
The dev org is about 170 devs
eula5nacc9457@reddit
reminds me of something i read last month
kbielefe@reddit
You're probably feeling a bit of impostor syndrome because you're not a DDD expert yet. You don't need to know everything now. The secret to being seen as an expert isn't to be super smart, it's to get a head start on your colleagues.
Think through the first few weeks of design decisions on the new project. What will you need to know in order to feel confident making those decisions? Learn that now. See what tools and advice is out there from other companies and figure out how it applies to this new project. Then you'll feel confident to start making some recommendations. You're fortunate to have a real project to think through instead of a hypothetical one. Take advantage of that.
rayfrankenstein@reddit
Here’s the million dollar question that nobody wants to talk about: what happens to all the legacy code that’s been previously written before the introduction of best practices, that might be in extreme non-compliance with newly decided- upon best practices?
SplendidPunkinButter@reddit
Managers love it when you give a presentation. They also have no idea if it was a good presentation or not.
margnal@reddit
You’re approaching this is the right way. Writing a strategy doc, for the sake of writing a strategy doc, is a waste of time. It’s a solution in search of a problem.
I found this article by Will Larson to be helpful in these kinds of activities in the past: https://craftingengstrategy.com/strategy-steps/
You’re in Step 1 right now (exploring wider industry practices). There are several following steps that help you take industry learnings and apply them to your specific organization’s problems. That part is key - just imagine yourself being handed a “How we do X” document from a peer engineer without any context as to why it was written, or what problems the strategy intends to solve, would you adopt it? Most people don’t, without that context.
The steps in that ^ guide will also help you frame progress to your manager. You’re not spinning your wheels with nothing to show for it, you’re taking a methodical approach so that your document actually sticks with its intended audience.
galwayygal@reddit (OP)
Love that! Thanks so much for sharing. I posted here to get advice like yours :)
throwaway_0x90@reddit
You are at a level where excuses are generally frowned upon. You have to find a way. Certainly being senior and potentially heading for staff there's almost nothing you can say to justify being blocked.
mastermindchilly@reddit
I caution you to develop best practices on what you see is currently working, not just studying up on a methodology and labeling it as best practices. This reduces the risk of you trying to force your projects into something when the shoe simply doesn’t fit.
Beyond defining the best practices, having practical ways of enforcing best practices is a high value problem to solve, whether this be linting, code review standards, ai agent prompts, deployment playbooks, etc.
compubomb@reddit
As a senior Dev of 17yrs, I'd just consult an LLM on the first draft. Then use it to build you a presentation using remotion.
tankerton@reddit
An aspect of engineering is sifting what works and doesn't work. Usually the proof point for this kind of thing is how you and your team have implemented it with business metrics, but you don't get there unless you adopt first.
Making the adoption case usually does require researching the industry best practices and divesting them to your stakeholders as the way to do X. This research should include your discernment of hype vs tangible results and why you think that.
You need to be doing research to lead your team to success in DDD and present engineering thought leadership to your company so your boss can bargain for a raise/promotion based on your ability to impact the companys entire engineering org, not just you or your team
bigjimbaker@reddit
You’re a senior, do your research, compile some points and filter out the noise. Take initiative and see what works/doesn’t work in personal projects.
If you have not used these technologies at scale, learn from those who have. It’s as much for you as it is for others as you will be asked to lead in those best practices.
It’s also just a starting off/intro doc. Does not need to be set in stone. You will learn what works for your team as the project evolves. Keep it high level and focused on agreed upon industry standards.
SquiffSquiff@reddit
So your manager is asking you to write a best practices document on something that you have yourself only theoretical knowledge of to be shared with the entire company? WCGW? Personally, I would be very cautious about writing a best practice guide even on stuff that I was very familiar with just for my own team of a few people as a senior.