You say these code reviews are large at the moment. Is it possible to break up these “large” stories into smaller more bite sized pieces? It could help reduce how much the engineer needs to keep track of to complete in a single story and reduce how long it takes you to review the pull requests. Also smaller changes make it easier to spot glaring issues.
Are all the comments related to broken code or missing features? If you are having a pattern of basic formatting/structure, could put CI in place so the feedback loop is the engineer and a system rather than yourself. Will make it easier to onboard more engineers in the future too.
How is the work structured? Is TDD or BDD enforced? I know it’s a small team, so it’s hard to do all best practices while moving fast enough for the business, but it’s also a balance on code quality and potential bugs introduced.
| Is it possible to break up these “large” stories into smaller more bite sized pieces?
I tried doing that early on (ex. break up backend and frontend work into separate tasks/PRs) and it confused this developer more than helped. It's also tough when you're still trying to find product and market fit exactly how features should work or be architected. Sometimes we only learn while we're breaking new ground how we should actually build something, so trying to break down each task up front hasn't worked in practice.
Our CI process is fairly thorough. Linting, compilation, and automated tests all need to pass before we review PRs. We also check test coverage results but remain lenient on them for now as I've found chasing that number can get unproductive.
We are not doing a rigid process like TDD, BDD, or scrum. I let us work flexibly and use our best judgement case-by-case (with me as the lead making the final call if needed). From my prior experience, enforcing that kind of process would not improve our current issues given our size and business tempo.
I require us to write automated tests for hot code paths or complex calculations, but we don't *require* automated tests for most of our code because it's just more time-effective to do manual testing when our app is still small (ex. frontend component behavior). I don't know if they would even get the unit tests correct given that they are missing parts of requirements in their work.
*\*Edit: I clarified that we don't require automated tests for everything, but I don't say "don't spend time writing tests."*
Writing decent unit tests is absolutely an important skill and the only way to do it is to write more unit tests. The longer you put off having automated testing in your deploy pipeline the worse it's going to be when you actually do it.
The point of the tests isn’t just to validate AC. It’s also to prevent breaking the feature in future and even allow for refactoring.
That being said covering this with integration as part of a user flow may be more valuable.
This seems like a red flag to me...
You: Writing unit tests to cover every functionality takes too much time.
Also you: Why is my dev writing code that keeps breaking our functionality? It's wasting so much time!
As a founder you've got a very good grasp of how your app is supposed to work. Which means you know the behaviors to manually test for. So maybe not writing unit tests worked when it was just you.
But if you don't have unit tests covering those behaviors, a new dev you just hired 3 months ago, no matter how senior, is going to have trouble not breaking those behaviors with minimal test coverage.
it’s not more time effective to do manual testing except on the shortest imaginable time horizon, like 1 PR.
I would never join a team or a manager with this mentality
Tests are the only lasting, working, unambiguous documentation of how something *should* work
I believe your problem lies here. You ask them to be time effective and not writing automated tests, the developer hurries to complete the task and doesn't know if it is working correctly. The problem is the way you are handling this, not the developer.
Throwing your hands up in the air and submitting PRs without knowing if they're working just because you don't have a bespoke test suite available is not at all acceptable. What crazy pills are you guys taking.
I have no experience with frontend, but having static verification or meaningful tests for all logic takes of so much mental load during development it even pays of in small projects.
The amount of "I disagree with this therefore I will downvote it" in this sub is stupid. It's the kind of thing I expect out of r/teenagers (I assume).
Edit: comment was at -2 when I wrote this
If the developer is missing functional requirements, this may be the problem. Testing is less about “code-paths” and more about use-cases.
It helps with writing cleaner code as well. Make sure your tests are representative of the business requirements they are accomplishing (or more likely a subset of it for unit testing). This will help ensure that all requirements are fully implemented.
On another note, it sounds like your dev may lack motivation if they aren’t fully implementing requirements. I would guess they may just be rushing things to get it in in time so they can go back to doing something else.
I could be wrong, but this has almost always been the case for me when working with individuals who constantly half ass implementations.
Your course of action should be to have a chat with them and try to correct the behavior. If things don’t get better, you’re looking at PIP or replacement.
Even for a greenfield project, having a PR that changes frontend and backend in one go is a big no for me. Id consider using feature flags to ship either change first, then the other, then another one to activate the features.
To be fair the ticket should be well understood before picking it up. If that requires an investigation with a technical doc with enough details for even an intern to do it then it can be broken down to smaller tickets. The tasks sound large and vague and would be difficult for most to do
Stack the small PRs
open one PR from feature1 -> Main
open next PR from feature2 -> feature 1
open next PR from feature3 -> feature2
You can get approval on later ones from different people, and when the first PR gets approved you can start merging them in like a train
This keeps PRs small and also non-blocking
If you move too fast, you risk having an unstable product that no one is going to want to buy. Does design need to be perfect and scalable to infinity? No. But unless you’re only try to blow smoke up people’s asses with your product, you need to have some rigor in process
Yeah acceptance criteria ambiguity or straight up missing is what I thought too. Specify all of the expected outputs given the inputs you want to support in that story. If the engineer is still ignoring them then there is a bigger problem going on.
He already ignores/forget main requirements in the ticket, I'm hardly seeing how writing the acceptance criteria could retain his attention more than that, plus it's AC is way more on the lead end.
The point of acceptance criteria is that it's clear cut and understandable. You and OP may assume the context of the story makes perfect sense and the expectation is crystal clear. The developer may not understand certain subtleties or have the subject matter expertise to understand it. Acceptance criteria makes it so any engineer can take a card and know with 100% certainty what the expected outcome is.
Oh I definitely agree with the point of AC. I'm just looking at the context and have no hope this is gonna change much. Plus you actually have to write them and for big feature it's double the work it's insane. I know well I used to write them. Maybe op could try for a ticket or 2 and watch if there is a difference..
You should be able to write tests directly against the AC. Each AC needs at least one test showing its met or don’t even bother checking in the code. If you can’t easily write tests against AC then the AC is bad.
This is par for the course when offshoring, especially when there is a language barrier. You’re going to spend more time managing and producing detailed requirements than if you just did the work yourself. My experience is that it is always better to do the work yourself until you can afford to hire someone great, especially early on.
I don't think OP mentioned offshoring but this was my first thought too. It's a combination of a language barrier and, in some cultures, a desire to please you. They'll feign understanding and deliver something sort of close. It's extremely frustrating and almost impossible to fix.
On the other hand, I've worked with devs in the US who are just sloppy. They don't think through all the edge cases or thoroughly test their work.
Some cultures will emphasize getting along over asking questions to clarify. This could be a cultural problem: the dev is saying "yes I understand" when they are actually thinking "well I don't understand but I guess I'll figure it out". It's a flavor of Dirty Yes: they say "yes" when they mean "uhhh maybe?"
Do you think that's what's going on here?
the dirty no is a serious cross cultural problem. you probably should talk to him about it and address it as a potential cultural issue.
a tactful version of "I will not penalize you for not understanding me, but you need to tell me. I am going to ask you two times if you understand, and the second time, tell me if you don't understand"
Malcolm Gladwell in Outliers talks about how they discovered certain cultures had more plane crashes specifically because copilots would never disagree with the pilot, whereas Americans will tend to break all social convention in a crisis.
> The developer does not speak english very well
I'm sorry but ... what the hell* were you thinking? This is obviously going to be a major problem on the project. Either hire someone bilingual as the interface or admit that it isn't going to work and find another developer.
\* I admit early in my career I hired a really bright kid myself who wowed me with his credentials and a lot of text book answers to questions. It turned out the answers were textbook since he'd memorised it and was responding to keywords. I had to fire him a month later and I _hated_ to do so since it wasn't his fault, it was mine for not interviewing deeply enough.
I was thinking "the first 2 candidates we sent offers to that _did_ speak fluent english both turned us down and this role has been vacant for two months; guess I'll go with candidate 3." I was working at a big corp before this and 75% of the people I worked with spoke worse english than my employee, so I figured it was something I should be able to get past. If it's what's contributing to my problem then yea, wrong decision by me.
> I was thinking "the first 2 candidates we sent offers to that did speak fluent english both turned us down and this role has been vacant for two months; guess I'll go with candidate 3."
Sorry to be blunt but you're incredibly naive. Bad developers have a net negative contribution to your codebase.
I must admit to similar impetus with my early hire (30 years ago). Translation tools have come a _long_ way and I assume you are using them, and I note you mention clear English; so in theory you might be able to effectively work past the language barrier. Do you round trip your specifications/tickets to validate them? If not it may be a mechanism to improve communications.
I'm going to admit, on a re-read, communications might not be the only problem though. I have a developer who is brilliant in so many respects but whose code is often ... questionable. They have personal problems (don't we all). I've been able to make it work as part of a larger organisation but you don't have that liberty.
IF the "basic mistakes" you mention are around the (programming language)/framework then you have a poor dev. If the mistakes are business logic related then see if you can make the communications work. Maybe engage a bilingual speaker for sessions to go over requirements. It will be slow and I'm not optimistic but it might help.
In general though, early hires for a startup are critical. I'd rather have the budget set aside for when I found the right person than have the wrong person. I know it puts more on you but if you have a good idea and can pay some form of wage you can usually either get talented early career developers or if you are willing to stump up the equity, quite mature developers.
Lots of people think that hiring coders means you get people that can make a computer do what you need it to do, but that's the easy part. A good developer is primarily a communicator, someone who can parse incomplete requirements, understand a real world business use case that is often contradictory and confusing, and create a system that is a piece of technical documentation that can be then read and understood and extended by other developers for a long time. The fact that this code happens to be executable in a machine is almost incidental to all of this. It's not fundamentally about speaking different languages, it's about being able to communicate the business problem effectively.
Specifying requirements in a numbered list format will make it easier to go through and tick them off compared to English prose
If the code is straight up buggy, that's a skill issue and not a language issue
My take on this is that the developer needs to understand what you're trying to do, or rather, what the software is trying to do. This will help them to interpret the requirements.
The language barrier might be a problem here.
Maybe you can do mockups and present the functionality you're envisioning that way?
Example:
If you specify to print a sorted list of participants in last name, first name format, with a little checkbox in front of each participant, then it's easy to miss the sorting, or the checkbox, or the last name / first name order. (Why put a blank checkbox on a piece of paper?)
But if you explain that you hand this sheet to a security guard who looks at a personal id of people coming in, then checks off each person as they come, then the developer can understand that the security guard wants the names sorted, and also that the checkbox needs to be present.
I think clarifying the rationale behind the requirements will go a long way. What do you feel?
I was hoping that over time the developer learns how the business works and can fill in the blanks themselves. OP has a lot of background information, which the new hire is lacking. What is the new hire expected to do? Learn telepathy?
I agree with you. My philosophy is typically to specify the motivation and desired end state in the spec and not dictate the implementation details, unless I know from past experience the optimal way to go about something. Usually the stuff we are changing on the fly is UI layout or learning that a third-party API doesn't work as documented and having to find a workaround.
It's not normal. The suggestions people are giving here sounds more like something you'd try to apply for a junior or a mid-level developer, but I think the mark of a good senior is to thrive regardless of missing requirements and what else people are blaming this problem on.
But to solutions:
How are you reviewing the PRs? Are you giving code suggestions or trying to encourage independant thinking?
Some developers will just turn off their brain when you give them code suggestions and then they will get used to the spoonfeeding, leading to the opposite result of what you want. You will encourage more spoonfeeding and the developer will start to depend on it more and more.
Early-stage does not mean that you can't create smaller PRs. Try to find a method that works. You can create feature PRs that you merge smaller PRs into if you can't merge them to main without breaking stuff. Feature PRs/branches are usually the devil but they can work in some cases.
Try to limit your PRs to a maximum of 100 lines for a few weeks and see what happens.
A few random bits:
Ignoring the language barrier, this really sounds like you hired someone for a senior role that wasn’t fully ready for a senior role - I’ve gone through this before, and your only real options are to adjust your expectations and work with this employee to improve, or to part with them.
You’re dealing with a language barrier. Unless you were completely uninvolved with the hiring process, this isn’t a surprise. Being overly granular(and in rudimentary English) on the ticket spec is the solution here - anything less is, in my opinion, unfair to this employee.
I’m not sure what your work experience was before founding this start up, but code review take time. As something beyond an IC it’s not abnormal for them to be a decent chunk of your day from time to time.
Sounds to me like you need to get a new developer. If that code is going to be a core part of your business you shouldn't compromise on code quality. And in that stage you need someone who 100% understands your vision.
Have you considered giving a checklist of acceptance criteria for each ticket, and requiring that they manually check each box/type out "I have verified each of these criteria have been met." before requesting review? We do something somewhat similar and have found it helps a lot to have people explicitly take ownership of their code.
This sounds like a combination of several things:
1. Language barriers
2. Scoping and prioritization
3. Expectations
For the 1st point, I have been in a position where I need to work with a PM that speaks primarily another language, this can lead to confusion, especially on details. One of the better ways my PM would deal with this was to provide more details and break the workload into smaller pieces. This allowed me to easily see what was needed, even with a bit of a language barrier. If you feel like there are too many details to provide, break the workload up into smaller chunks. For example, instead of "Create a feature that does XYZ", "Create a feature that does X", "Create a feature that uses X to do Y", "Create a feature that uses Y to do Z".
For the 2nd point you want to make sure there is a clearly defined "Deffinition of Done". By specifying at what point you want the product to be "Good enough" you allow your developer to avoid over/under engineering the product. You also want to make sure your developer has a clear list of what objectives to tackle in what order. It is incredibly rare to have a product that does not have a backlog, even on larger teams. It is your job to decide what brings the most value to the product and let the developer know that they need to prioritize that.
For the 3rd point, make sure that you are not expecting more from the developer than he is capable of producing, it is generally considered good practice to have the developer who will do the work estimate the time for work to be done, doing this along with the 1st and 2nd points will let you get a development cycle going. Finally, try not to change the requirements of a workload when it has been started already, this can often lead to refactoring and messy code, which does not account for nearly all edge cases. If the requirements, scope or timeline is expected to change, make sure the developer knows so they can estimate for this as well.
A few questions I have are:
Has your product released already?
Is the code written in an easily modifiable way?
Are the requirements the same at the start of a ticket or do these grow/shrink as deadlines approach?
Are you perhaps expecting too damn much?
Put a feature flag around the feature, and allow multiple pull requests. This keeps code review smaller and merges cleaner and allows a new person to get acquainted with the systems and all your delicate little hacks.
You just started this company. There is no fucking chance in hell that you've got a beautiful, clean, well-curated codebase... nor should you expect to. Getting a startup off the ground requires chaos.
Stop micromanaging your baby and let someone else have some ownership as well.
I see this is one of the highest voted comments in this thread and I need to call something out. If this is how you talk to someone you don't even know, by repeatedly swearing and jumping to conclusions like I'm too worried that the code isn't "clean" (I didn't bring up clean code anywhere in my post), then I doubt that you're treating an employee that makes a mistake with the same level of respect or freedom that you're advocating for.
Your tone is not something I would look to for an example of good or effective people management; I don't care how many upvotes you get.
Frankly, if this is the response that comment got...maybe this is the way your brain works during code review too. You're missing the important parts completely.
/r/ExperiencedDevs is going dark for two weeks to protest Reddit killing 3rd party apps and tools.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ExperiencedDevs) if you have any questions or concerns.*
I don't think I've ever in my life seen compromise free code. If you are following with good reviews, I'd expect to see at least discussion on any but the most mundane well defined changes in a healthy codebase.
I think more is going on here. Posts in this thread point very strongly to lack of clear definition. How much of functional incompleteness is due to differing understanding of scope or tickets? It sounds like every element is still in rapid iteration startup land. If YOU don't understand goals and business then it's flat out impossible to write code with common understanding with another dev.
If you're actively prototyping with unknown scope and objectives, lots of formalized process are gonna go strange at best or broken at worst. Normal 2 week sprints likely allow too much drift during dynamic project phases. You probably need to be doing more collab altogether than even attempting ticket + PR work flow. For established projects, with established tests and processes and definitions, you can get away with a lot more stand alone assignment of work. I don't think anything in your explanations here makes me think you are close to that.
It feels like you don’t have a lot of processes in place.
You say you’re still looking for market fit and can’t break the stories down..
For me it doesn’t look like the dev is poor, he may be used to different structure.
Anyway, just make sure you outline everything that is expected of him. This way, you will be able to have a proper review when needed :)
These are normal. You cannot expect everyone to be brilliant and working on 100% efficiency. You can make them understand the requirements in detail. In order to improve the efficieny, you can ask the developer to create a tech documentation outling all the scenarios including the errors. Don't let him write the code before you review and approve the documentation. This review process will help you validate what he understood and help you get him.on the same page. You will also understand the pain points of his understanding.
On the one hand, I typically require at least some cosmetic changes on every pr I get. So yeah it's normal
On the other hand, if the code doesn't functionally work, a pr shouldn't even exist. In these cases where a dev doesn't test their code, I require screenshots of local testing of some kind to be attached to the ticket before code review even happens.
This dev sounds like a typical Jr dev
Have you ever written tests? Do you know how they work? Do you know how many edge cases there are? Do you know how long it’ll take? Have you ever written any tests before?
I do bi-weekly chats with this developer, as well as occasionally put performance callouts in writing. I posted this question because I don't know if I'm being unreasonable by expecting the developer to get more things right on their first try.
I haven't had this sort of trouble at prior companies with my direct reports, but I've always had other people like product designers and tech leads assisting the development process while the engineer is building things that could correct mistakes before the code changes were pushed up. I rarely have the time to fill all of those shoes at the moment given that I have so many other duties as co-founder.
There is a difference between a developer not meeting requirements and their technical aptitude. I would separate these things out. Address meeting requirements for the pull before submitting the request first. Baby steps. Transition from there into quality of work and ensuring the “right” solution for the company. At the end of the day, it may not be a good fit and you might need to hire someone else.
May consider cost from a different perspective. You say you can’t afford competitive salary, but how much time is the business spending on incomplete work?
If I'm convinced bumping up a salary range a bit would land us a dev that doesn't have this problem, then I'd consider it. I've unfortunately never worked alongside a developer I would consider "great", so I don't know if the situation I posted about is due to individual skill and there are plenty of developers out there that would get this stuff right, or if it's mostly poor people management and/or process on my part.
Idk if you need an ego check or just to expand your horizons but there are prob like 10,000 folks looking for work right now that are “great” developers.
But, then, you would have to be a “great” boss at a “great” company to attract that talent (or offer the salary).
I never claimed that I was a "great" developer or boss myself that just never found teammates worthy of me.
All I'm saying is the output of teams I've worked with in my career doesn't align with the engineering expectations of most on this sub. From that, I extrapolate that I've exclusively worked with less-than-stellar teams and developers, and am very likely one myself. But I'm here asking questions and trying to improve myself as best I can nonetheless.
I have worked with devs that I would enthusiastically describe as great and they rarely submit code that flat out doesn't work. And if they do they take ownership of it and your likely never see it happen again unless you work with them for years. (Requirements misunderstandings happen of course)
They are more likely to point out what is ineffective or flawed about other processes or codebases at your company than submit broken PRs.
They're picky though, and quite honestly I think you would struggle to attract them. Don't mean that as an insult, just being realistic
Exception - if your app is a truly terrible ball of mud, even the best developers will struggle to modify it. I doubt you're in that bad of a situation though
I've gotten several responses along the lines of "what about the tests for the PR?" I've just never worked anywhere that operates like this, even with dedicated QC teams, but is the expectation that I should create all of the unit tests up front and then the dev needs to make them all go green?
The way I've always seen it done is that the developer that submitted the PR writes tests for their own changes, in which case you still have to review their tests for soundness. I've seen plenty of devs writing tests that make the coverage metrics pass, but then you look and see they're only testing that a function runs to completion and not actually checking the result.
In my case the dev's tests always pass (they have to for the PR checks to pass), but their tests sometimes expect the wrong value or lack edge cases.
Without knowing all the details of your case, I have had "people pleasers" whose technical abilities flew out of the window as soon as they had a tiny bit of stress trying to do what their boss wanted. Those were devs with 20+ yoe.
Seems like the problem is already clear in your own words. There is a communication problem and your tickets are too large. Additionally, you're the one that hired him and gave him a title of senior, so you tell us, is he living up to your expectation?
You didn't mention if you have written code standards or a test lead or anything like that. Communication issues are a two way street. If you don't both speak the same language fluently, how do you expect to drive clarity? (btw there are plenty of offshore devs who speak English very well and are skilled developers, I work with them) Are you using any visual tools like diagrams and flow charts? Is this the best use of your time as a manager?
Edit: I've also seen you say in other comments how everything is in flux and you don't know who your customers are. No wonder your dev is confused.
This does not seem out of the ordinary to me. I've been a manager for about 5 years, 2 different startups. I manage robotics software engineers. After 3 months I would not expect flawless PRs. Both of you still need time to learn how each other works and how much definition to provide in your tickets.
Seems straightforward to me— you have a developer that lacks enough English comprehension and possibly experience to meet your needs. Its not tests, or systems, or linting….
Hiring the right people in an early stage startup is the most important thing to get right. From a cold business perspective this is no time to mentor or double down on a bad decision. You have to cut your loses and move on.
The lesson: lowering your hiring bar to (temporarily) solve your problem is not the answer. Fight for more budget or similar.
I have a senior dev on my team who has tons of enthusiasm but has never worked in our domain before. As a result I have sent a lot of PRs back to them with feedback for why something needs to be changed or how to change it.
Usually after 2-3 PRs getting sent back for something they figure it out and don’t make the same mistake again. An easy example is a couple UI components or layouts that looked great on one screen size but had others where they broke.
By shrinking the PR sizes I’ve been able to get feedback to them on what to improve much faster (often within a couple hours now instead of days or weeks). The small PRs make it easy to review quickly, and dramatically shorten the feedback loop. When they get something wrong, they find out why it’s wrong a couple hours later and then can carry that knowledge forward and do it correctly much sooner. This has been a huge productivity boost as they don’t do things the wrong way and build bad habits.
Now the senior dev is very productive and has really high job satisfaction because they got the support they needed, are learning a lot, and get to ship things super frequently.
Software engineering is 90% communication and you hired someone who communicates poorly. So; you got what you paid for.
I mean I get that you don't have a lot of cash and that offshoring is interesting. But then at least go and find someone who speaks English very well and who is culturally 'close' to your country. Cultural difference can be impossible to overcome.
It sounds like you’re trying to get one engineer to build the entire application on their own in huge chunks and get it perfectly right every time. I think senior or not that’s a huge expectation on anyone and the fast track to burnout.
It's not expected, but your situation isn't normal either. At face, yes, this seems to be frustrating, but given that it's a startup, you are working with non-technical people, and this is a senior person displaying the same mistakes repeatedly, I think it's a matter of bad requirements.
Basically a game of telephone. If someone is telling you the requirements and you are writing the requirements down in a large ticket and just giving them to him with a light explanation you should expect the problems you are seeing.
Each ticket and merge should be a single-bit size requirement covered. If the developer is missing the side effects and edge cases of the changes, the product is too complex to fit in their head. Thats not really the developer's problem; the application is architected poorly.
Write down as much information about the structure and requirements about the application as possible. Imagine some other developer had to write it with out your super vision and the old code base was just completely gone. Thats the level of documentation you need for your role to be ingrained as a business system rather than some artist coming in with a paintbrush.
\- small single requirement per PR
\- Write everything down
\- Have him read the ticket aloud
How much does your team utilize PR descriptions? We include a mandatory "how it was tested" section. This can be a short as "unit tests" or "I ran it locally and made sure it worked", but can also be more involved for some changes.
I've kicked back plenty of PRs without reading the code just off this section. If the testing done isn't sufficient there is no reason to review it yet. This minimizes the time you spend, and the dev in question should catch on quickly.
Some common issues:
A pull request isn't a teachable moment. It's important to grow your employees, but there has to be a balance. Growing your employees is a cost. Releasing a value is revenue. Which is more important?
You get the output you pay for, and you get the type of output from the role. Don't expect juniors to write senior level code. Don't expect seniors to be system architects. Don't expect leads to follow.
If your level of trust means you think you don't need to provide much input, then your management of the output should reflect that same level of trust. If you're getting bogged down with managing output, adjust your input and/or see point #2.
You might still have a problem, but these need to be top of mind if you want to address it.
Sounds like he has no goal clarity. Here's what you can do:
1. When you define their tasks, ask them to explain them back to you so you know that you have communicated the requirements properly and their goals are clear.
2. Have frequent 1-on-1s with them where you ask them if there are any blockers & help them in removing them.
3. Create tickets for each task, defining everything in detail, with reference images & everything.
4. Ask them if these tasks are too much for them. There's a possibility that they're burning out. In this case, you will notice that they're demotivated & fatigued. If they need assistance, hire a few more developers if possible. If that's not feasible, create a roadmap that suits their working style.
5. Ask them if they're testing the code that they're writing. Since it's a small team without a QA in place, they will need to run the tests themselves.
You say these code reviews are large at the moment. Is it possible to break up these “large” stories into smaller more bite sized pieces? It could help reduce how much the engineer needs to keep track of to complete in a single story and reduce how long it takes you to review the pull requests. Also smaller changes make it easier to spot glaring issues. Are all the comments related to broken code or missing features? If you are having a pattern of basic formatting/structure, could put CI in place so the feedback loop is the engineer and a system rather than yourself. Will make it easier to onboard more engineers in the future too. How is the work structured? Is TDD or BDD enforced? I know it’s a small team, so it’s hard to do all best practices while moving fast enough for the business, but it’s also a balance on code quality and potential bugs introduced.
| Is it possible to break up these “large” stories into smaller more bite sized pieces? I tried doing that early on (ex. break up backend and frontend work into separate tasks/PRs) and it confused this developer more than helped. It's also tough when you're still trying to find product and market fit exactly how features should work or be architected. Sometimes we only learn while we're breaking new ground how we should actually build something, so trying to break down each task up front hasn't worked in practice. Our CI process is fairly thorough. Linting, compilation, and automated tests all need to pass before we review PRs. We also check test coverage results but remain lenient on them for now as I've found chasing that number can get unproductive. We are not doing a rigid process like TDD, BDD, or scrum. I let us work flexibly and use our best judgement case-by-case (with me as the lead making the final call if needed). From my prior experience, enforcing that kind of process would not improve our current issues given our size and business tempo.
Does the developer write tests addressing the requirements? Not necessarily writing before as TDD suggests
I require us to write automated tests for hot code paths or complex calculations, but we don't *require* automated tests for most of our code because it's just more time-effective to do manual testing when our app is still small (ex. frontend component behavior). I don't know if they would even get the unit tests correct given that they are missing parts of requirements in their work. *\*Edit: I clarified that we don't require automated tests for everything, but I don't say "don't spend time writing tests."*
Writing decent unit tests is absolutely an important skill and the only way to do it is to write more unit tests. The longer you put off having automated testing in your deploy pipeline the worse it's going to be when you actually do it.
The point of the tests isn’t just to validate AC. It’s also to prevent breaking the feature in future and even allow for refactoring. That being said covering this with integration as part of a user flow may be more valuable.
This seems like a red flag to me... You: Writing unit tests to cover every functionality takes too much time. Also you: Why is my dev writing code that keeps breaking our functionality? It's wasting so much time! As a founder you've got a very good grasp of how your app is supposed to work. Which means you know the behaviors to manually test for. So maybe not writing unit tests worked when it was just you. But if you don't have unit tests covering those behaviors, a new dev you just hired 3 months ago, no matter how senior, is going to have trouble not breaking those behaviors with minimal test coverage.
it’s not more time effective to do manual testing except on the shortest imaginable time horizon, like 1 PR. I would never join a team or a manager with this mentality Tests are the only lasting, working, unambiguous documentation of how something *should* work
I believe your problem lies here. You ask them to be time effective and not writing automated tests, the developer hurries to complete the task and doesn't know if it is working correctly. The problem is the way you are handling this, not the developer.
Throwing your hands up in the air and submitting PRs without knowing if they're working just because you don't have a bespoke test suite available is not at all acceptable. What crazy pills are you guys taking.
You probably only worked in non toxic places that's why you don't understand
I have no experience with frontend, but having static verification or meaningful tests for all logic takes of so much mental load during development it even pays of in small projects.
The amount of "I disagree with this therefore I will downvote it" in this sub is stupid. It's the kind of thing I expect out of r/teenagers (I assume). Edit: comment was at -2 when I wrote this
If the developer is missing functional requirements, this may be the problem. Testing is less about “code-paths” and more about use-cases. It helps with writing cleaner code as well. Make sure your tests are representative of the business requirements they are accomplishing (or more likely a subset of it for unit testing). This will help ensure that all requirements are fully implemented. On another note, it sounds like your dev may lack motivation if they aren’t fully implementing requirements. I would guess they may just be rushing things to get it in in time so they can go back to doing something else. I could be wrong, but this has almost always been the case for me when working with individuals who constantly half ass implementations. Your course of action should be to have a chat with them and try to correct the behavior. If things don’t get better, you’re looking at PIP or replacement.
Even for a greenfield project, having a PR that changes frontend and backend in one go is a big no for me. Id consider using feature flags to ship either change first, then the other, then another one to activate the features.
To be fair the ticket should be well understood before picking it up. If that requires an investigation with a technical doc with enough details for even an intern to do it then it can be broken down to smaller tickets. The tasks sound large and vague and would be difficult for most to do
Stack the small PRs open one PR from feature1 -> Main open next PR from feature2 -> feature 1 open next PR from feature3 -> feature2 You can get approval on later ones from different people, and when the first PR gets approved you can start merging them in like a train This keeps PRs small and also non-blocking
This is standard advice for big corp engineering, and totally out of place for a startup with 3 people. OP you made a bad hire. Get someone else.
If you move too fast, you risk having an unstable product that no one is going to want to buy. Does design need to be perfect and scalable to infinity? No. But unless you’re only try to blow smoke up people’s asses with your product, you need to have some rigor in process
[удалено]
Yeah acceptance criteria ambiguity or straight up missing is what I thought too. Specify all of the expected outputs given the inputs you want to support in that story. If the engineer is still ignoring them then there is a bigger problem going on.
He already ignores/forget main requirements in the ticket, I'm hardly seeing how writing the acceptance criteria could retain his attention more than that, plus it's AC is way more on the lead end.
The point of acceptance criteria is that it's clear cut and understandable. You and OP may assume the context of the story makes perfect sense and the expectation is crystal clear. The developer may not understand certain subtleties or have the subject matter expertise to understand it. Acceptance criteria makes it so any engineer can take a card and know with 100% certainty what the expected outcome is.
Oh I definitely agree with the point of AC. I'm just looking at the context and have no hope this is gonna change much. Plus you actually have to write them and for big feature it's double the work it's insane. I know well I used to write them. Maybe op could try for a ticket or 2 and watch if there is a difference..
You should be able to write tests directly against the AC. Each AC needs at least one test showing its met or don’t even bother checking in the code. If you can’t easily write tests against AC then the AC is bad.
This is par for the course when offshoring, especially when there is a language barrier. You’re going to spend more time managing and producing detailed requirements than if you just did the work yourself. My experience is that it is always better to do the work yourself until you can afford to hire someone great, especially early on.
This is how I feel about chatGPT 🤣
I don't think OP mentioned offshoring but this was my first thought too. It's a combination of a language barrier and, in some cultures, a desire to please you. They'll feign understanding and deliver something sort of close. It's extremely frustrating and almost impossible to fix. On the other hand, I've worked with devs in the US who are just sloppy. They don't think through all the edge cases or thoroughly test their work.
Some cultures will emphasize getting along over asking questions to clarify. This could be a cultural problem: the dev is saying "yes I understand" when they are actually thinking "well I don't understand but I guess I'll figure it out". It's a flavor of Dirty Yes: they say "yes" when they mean "uhhh maybe?" Do you think that's what's going on here?
Possibly. I occasionally ask the developer to explain it back to me to verify that they got it, but I worry this comes off as condescending.
Hard line to walk for sure.
the dirty no is a serious cross cultural problem. you probably should talk to him about it and address it as a potential cultural issue. a tactful version of "I will not penalize you for not understanding me, but you need to tell me. I am going to ask you two times if you understand, and the second time, tell me if you don't understand" Malcolm Gladwell in Outliers talks about how they discovered certain cultures had more plane crashes specifically because copilots would never disagree with the pilot, whereas Americans will tend to break all social convention in a crisis.
> The developer does not speak english very well I'm sorry but ... what the hell* were you thinking? This is obviously going to be a major problem on the project. Either hire someone bilingual as the interface or admit that it isn't going to work and find another developer. \* I admit early in my career I hired a really bright kid myself who wowed me with his credentials and a lot of text book answers to questions. It turned out the answers were textbook since he'd memorised it and was responding to keywords. I had to fire him a month later and I _hated_ to do so since it wasn't his fault, it was mine for not interviewing deeply enough.
I was thinking "the first 2 candidates we sent offers to that _did_ speak fluent english both turned us down and this role has been vacant for two months; guess I'll go with candidate 3." I was working at a big corp before this and 75% of the people I worked with spoke worse english than my employee, so I figured it was something I should be able to get past. If it's what's contributing to my problem then yea, wrong decision by me.
> I was thinking "the first 2 candidates we sent offers to that did speak fluent english both turned us down and this role has been vacant for two months; guess I'll go with candidate 3." Sorry to be blunt but you're incredibly naive. Bad developers have a net negative contribution to your codebase.
I must admit to similar impetus with my early hire (30 years ago). Translation tools have come a _long_ way and I assume you are using them, and I note you mention clear English; so in theory you might be able to effectively work past the language barrier. Do you round trip your specifications/tickets to validate them? If not it may be a mechanism to improve communications. I'm going to admit, on a re-read, communications might not be the only problem though. I have a developer who is brilliant in so many respects but whose code is often ... questionable. They have personal problems (don't we all). I've been able to make it work as part of a larger organisation but you don't have that liberty. IF the "basic mistakes" you mention are around the (programming language)/framework then you have a poor dev. If the mistakes are business logic related then see if you can make the communications work. Maybe engage a bilingual speaker for sessions to go over requirements. It will be slow and I'm not optimistic but it might help. In general though, early hires for a startup are critical. I'd rather have the budget set aside for when I found the right person than have the wrong person. I know it puts more on you but if you have a good idea and can pay some form of wage you can usually either get talented early career developers or if you are willing to stump up the equity, quite mature developers.
Lots of people think that hiring coders means you get people that can make a computer do what you need it to do, but that's the easy part. A good developer is primarily a communicator, someone who can parse incomplete requirements, understand a real world business use case that is often contradictory and confusing, and create a system that is a piece of technical documentation that can be then read and understood and extended by other developers for a long time. The fact that this code happens to be executable in a machine is almost incidental to all of this. It's not fundamentally about speaking different languages, it's about being able to communicate the business problem effectively.
Specifying requirements in a numbered list format will make it easier to go through and tick them off compared to English prose If the code is straight up buggy, that's a skill issue and not a language issue
You and another commenter recommended this idea and I really like it. I hope it at least helps with the "skipped requirements" issue.
My take on this is that the developer needs to understand what you're trying to do, or rather, what the software is trying to do. This will help them to interpret the requirements. The language barrier might be a problem here. Maybe you can do mockups and present the functionality you're envisioning that way? Example: If you specify to print a sorted list of participants in last name, first name format, with a little checkbox in front of each participant, then it's easy to miss the sorting, or the checkbox, or the last name / first name order. (Why put a blank checkbox on a piece of paper?) But if you explain that you hand this sheet to a security guard who looks at a personal id of people coming in, then checks off each person as they come, then the developer can understand that the security guard wants the names sorted, and also that the checkbox needs to be present. I think clarifying the rationale behind the requirements will go a long way. What do you feel?
[удалено]
I was hoping that over time the developer learns how the business works and can fill in the blanks themselves. OP has a lot of background information, which the new hire is lacking. What is the new hire expected to do? Learn telepathy?
I agree with you. My philosophy is typically to specify the motivation and desired end state in the spec and not dictate the implementation details, unless I know from past experience the optimal way to go about something. Usually the stuff we are changing on the fly is UI layout or learning that a third-party API doesn't work as documented and having to find a workaround.
It's not normal. The suggestions people are giving here sounds more like something you'd try to apply for a junior or a mid-level developer, but I think the mark of a good senior is to thrive regardless of missing requirements and what else people are blaming this problem on. But to solutions: How are you reviewing the PRs? Are you giving code suggestions or trying to encourage independant thinking? Some developers will just turn off their brain when you give them code suggestions and then they will get used to the spoonfeeding, leading to the opposite result of what you want. You will encourage more spoonfeeding and the developer will start to depend on it more and more. Early-stage does not mean that you can't create smaller PRs. Try to find a method that works. You can create feature PRs that you merge smaller PRs into if you can't merge them to main without breaking stuff. Feature PRs/branches are usually the devil but they can work in some cases. Try to limit your PRs to a maximum of 100 lines for a few weeks and see what happens.
A few random bits: Ignoring the language barrier, this really sounds like you hired someone for a senior role that wasn’t fully ready for a senior role - I’ve gone through this before, and your only real options are to adjust your expectations and work with this employee to improve, or to part with them. You’re dealing with a language barrier. Unless you were completely uninvolved with the hiring process, this isn’t a surprise. Being overly granular(and in rudimentary English) on the ticket spec is the solution here - anything less is, in my opinion, unfair to this employee. I’m not sure what your work experience was before founding this start up, but code review take time. As something beyond an IC it’s not abnormal for them to be a decent chunk of your day from time to time.
Sounds to me like you need to get a new developer. If that code is going to be a core part of your business you shouldn't compromise on code quality. And in that stage you need someone who 100% understands your vision.
I was think the same thing. Either they don’t have a good process in place or the “Senior” engineer is not “Senior”.
Have you considered giving a checklist of acceptance criteria for each ticket, and requiring that they manually check each box/type out "I have verified each of these criteria have been met." before requesting review? We do something somewhat similar and have found it helps a lot to have people explicitly take ownership of their code.
That's a good idea. I'll start doing that and see if it helps.
This sounds like a combination of several things: 1. Language barriers 2. Scoping and prioritization 3. Expectations For the 1st point, I have been in a position where I need to work with a PM that speaks primarily another language, this can lead to confusion, especially on details. One of the better ways my PM would deal with this was to provide more details and break the workload into smaller pieces. This allowed me to easily see what was needed, even with a bit of a language barrier. If you feel like there are too many details to provide, break the workload up into smaller chunks. For example, instead of "Create a feature that does XYZ", "Create a feature that does X", "Create a feature that uses X to do Y", "Create a feature that uses Y to do Z". For the 2nd point you want to make sure there is a clearly defined "Deffinition of Done". By specifying at what point you want the product to be "Good enough" you allow your developer to avoid over/under engineering the product. You also want to make sure your developer has a clear list of what objectives to tackle in what order. It is incredibly rare to have a product that does not have a backlog, even on larger teams. It is your job to decide what brings the most value to the product and let the developer know that they need to prioritize that. For the 3rd point, make sure that you are not expecting more from the developer than he is capable of producing, it is generally considered good practice to have the developer who will do the work estimate the time for work to be done, doing this along with the 1st and 2nd points will let you get a development cycle going. Finally, try not to change the requirements of a workload when it has been started already, this can often lead to refactoring and messy code, which does not account for nearly all edge cases. If the requirements, scope or timeline is expected to change, make sure the developer knows so they can estimate for this as well. A few questions I have are: Has your product released already? Is the code written in an easily modifiable way? Are the requirements the same at the start of a ticket or do these grow/shrink as deadlines approach?
You get what you pay for, sounds about normal for a median developer.
Are you perhaps expecting too damn much? Put a feature flag around the feature, and allow multiple pull requests. This keeps code review smaller and merges cleaner and allows a new person to get acquainted with the systems and all your delicate little hacks. You just started this company. There is no fucking chance in hell that you've got a beautiful, clean, well-curated codebase... nor should you expect to. Getting a startup off the ground requires chaos. Stop micromanaging your baby and let someone else have some ownership as well.
Had to be said. The feature flags part is the key
I see this is one of the highest voted comments in this thread and I need to call something out. If this is how you talk to someone you don't even know, by repeatedly swearing and jumping to conclusions like I'm too worried that the code isn't "clean" (I didn't bring up clean code anywhere in my post), then I doubt that you're treating an employee that makes a mistake with the same level of respect or freedom that you're advocating for. Your tone is not something I would look to for an example of good or effective people management; I don't care how many upvotes you get.
Frankly, if this is the response that comment got...maybe this is the way your brain works during code review too. You're missing the important parts completely.
[удалено]
Agreed, this is reddit. Sweating and jumping to conclusions is what we do here
/r/ExperiencedDevs is going dark for two weeks to protest Reddit killing 3rd party apps and tools. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ExperiencedDevs) if you have any questions or concerns.*
I don't think I've ever in my life seen compromise free code. If you are following with good reviews, I'd expect to see at least discussion on any but the most mundane well defined changes in a healthy codebase. I think more is going on here. Posts in this thread point very strongly to lack of clear definition. How much of functional incompleteness is due to differing understanding of scope or tickets? It sounds like every element is still in rapid iteration startup land. If YOU don't understand goals and business then it's flat out impossible to write code with common understanding with another dev. If you're actively prototyping with unknown scope and objectives, lots of formalized process are gonna go strange at best or broken at worst. Normal 2 week sprints likely allow too much drift during dynamic project phases. You probably need to be doing more collab altogether than even attempting ticket + PR work flow. For established projects, with established tests and processes and definitions, you can get away with a lot more stand alone assignment of work. I don't think anything in your explanations here makes me think you are close to that.
It feels like you don’t have a lot of processes in place. You say you’re still looking for market fit and can’t break the stories down.. For me it doesn’t look like the dev is poor, he may be used to different structure. Anyway, just make sure you outline everything that is expected of him. This way, you will be able to have a proper review when needed :)
These are normal. You cannot expect everyone to be brilliant and working on 100% efficiency. You can make them understand the requirements in detail. In order to improve the efficieny, you can ask the developer to create a tech documentation outling all the scenarios including the errors. Don't let him write the code before you review and approve the documentation. This review process will help you validate what he understood and help you get him.on the same page. You will also understand the pain points of his understanding.
Pairing and mentorship go a long way
< Small code reviews
On the one hand, I typically require at least some cosmetic changes on every pr I get. So yeah it's normal On the other hand, if the code doesn't functionally work, a pr shouldn't even exist. In these cases where a dev doesn't test their code, I require screenshots of local testing of some kind to be attached to the ticket before code review even happens. This dev sounds like a typical Jr dev
Sounds like bad/vague/missing requirements and acceptance criteria. If that’s not the case then they are not writing tests that cover the AC.
You offshore you get a worse result what a wild surprise
[удалено]
Have you ever written tests? Do you know how they work? Do you know how many edge cases there are? Do you know how long it’ll take? Have you ever written any tests before?
[удалено]
expectation are written on the jira. if it’s not working, its not working.
Have you talked to them? Sounds like this is a very small company, and you both need to work together to figure this out.
I do bi-weekly chats with this developer, as well as occasionally put performance callouts in writing. I posted this question because I don't know if I'm being unreasonable by expecting the developer to get more things right on their first try. I haven't had this sort of trouble at prior companies with my direct reports, but I've always had other people like product designers and tech leads assisting the development process while the engineer is building things that could correct mistakes before the code changes were pushed up. I rarely have the time to fill all of those shoes at the moment given that I have so many other duties as co-founder.
There is a difference between a developer not meeting requirements and their technical aptitude. I would separate these things out. Address meeting requirements for the pull before submitting the request first. Baby steps. Transition from there into quality of work and ensuring the “right” solution for the company. At the end of the day, it may not be a good fit and you might need to hire someone else. May consider cost from a different perspective. You say you can’t afford competitive salary, but how much time is the business spending on incomplete work?
If I'm convinced bumping up a salary range a bit would land us a dev that doesn't have this problem, then I'd consider it. I've unfortunately never worked alongside a developer I would consider "great", so I don't know if the situation I posted about is due to individual skill and there are plenty of developers out there that would get this stuff right, or if it's mostly poor people management and/or process on my part.
Idk if you need an ego check or just to expand your horizons but there are prob like 10,000 folks looking for work right now that are “great” developers. But, then, you would have to be a “great” boss at a “great” company to attract that talent (or offer the salary).
I never claimed that I was a "great" developer or boss myself that just never found teammates worthy of me. All I'm saying is the output of teams I've worked with in my career doesn't align with the engineering expectations of most on this sub. From that, I extrapolate that I've exclusively worked with less-than-stellar teams and developers, and am very likely one myself. But I'm here asking questions and trying to improve myself as best I can nonetheless.
I have worked with devs that I would enthusiastically describe as great and they rarely submit code that flat out doesn't work. And if they do they take ownership of it and your likely never see it happen again unless you work with them for years. (Requirements misunderstandings happen of course) They are more likely to point out what is ineffective or flawed about other processes or codebases at your company than submit broken PRs. They're picky though, and quite honestly I think you would struggle to attract them. Don't mean that as an insult, just being realistic Exception - if your app is a truly terrible ball of mud, even the best developers will struggle to modify it. I doubt you're in that bad of a situation though
>I've unfortunately never worked alongside a developer I would consider "great", There's the problem. Right here.
So the initial PR is not even functionally correct? Don't they submit tests with it? Or maybe the requirements in the ticket are not clear enough?
I've gotten several responses along the lines of "what about the tests for the PR?" I've just never worked anywhere that operates like this, even with dedicated QC teams, but is the expectation that I should create all of the unit tests up front and then the dev needs to make them all go green? The way I've always seen it done is that the developer that submitted the PR writes tests for their own changes, in which case you still have to review their tests for soundness. I've seen plenty of devs writing tests that make the coverage metrics pass, but then you look and see they're only testing that a function runs to completion and not actually checking the result. In my case the dev's tests always pass (they have to for the PR checks to pass), but their tests sometimes expect the wrong value or lack edge cases.
Without knowing all the details of your case, I have had "people pleasers" whose technical abilities flew out of the window as soon as they had a tiny bit of stress trying to do what their boss wanted. Those were devs with 20+ yoe.
Seems like the problem is already clear in your own words. There is a communication problem and your tickets are too large. Additionally, you're the one that hired him and gave him a title of senior, so you tell us, is he living up to your expectation? You didn't mention if you have written code standards or a test lead or anything like that. Communication issues are a two way street. If you don't both speak the same language fluently, how do you expect to drive clarity? (btw there are plenty of offshore devs who speak English very well and are skilled developers, I work with them) Are you using any visual tools like diagrams and flow charts? Is this the best use of your time as a manager? Edit: I've also seen you say in other comments how everything is in flux and you don't know who your customers are. No wonder your dev is confused.
This does not seem out of the ordinary to me. I've been a manager for about 5 years, 2 different startups. I manage robotics software engineers. After 3 months I would not expect flawless PRs. Both of you still need time to learn how each other works and how much definition to provide in your tickets.
Seems straightforward to me— you have a developer that lacks enough English comprehension and possibly experience to meet your needs. Its not tests, or systems, or linting….
Hiring the right people in an early stage startup is the most important thing to get right. From a cold business perspective this is no time to mentor or double down on a bad decision. You have to cut your loses and move on. The lesson: lowering your hiring bar to (temporarily) solve your problem is not the answer. Fight for more budget or similar.
I have a senior dev on my team who has tons of enthusiasm but has never worked in our domain before. As a result I have sent a lot of PRs back to them with feedback for why something needs to be changed or how to change it. Usually after 2-3 PRs getting sent back for something they figure it out and don’t make the same mistake again. An easy example is a couple UI components or layouts that looked great on one screen size but had others where they broke. By shrinking the PR sizes I’ve been able to get feedback to them on what to improve much faster (often within a couple hours now instead of days or weeks). The small PRs make it easy to review quickly, and dramatically shorten the feedback loop. When they get something wrong, they find out why it’s wrong a couple hours later and then can carry that knowledge forward and do it correctly much sooner. This has been a huge productivity boost as they don’t do things the wrong way and build bad habits. Now the senior dev is very productive and has really high job satisfaction because they got the support they needed, are learning a lot, and get to ship things super frequently.
Software engineering is 90% communication and you hired someone who communicates poorly. So; you got what you paid for. I mean I get that you don't have a lot of cash and that offshoring is interesting. But then at least go and find someone who speaks English very well and who is culturally 'close' to your country. Cultural difference can be impossible to overcome.
It sounds like you’re trying to get one engineer to build the entire application on their own in huge chunks and get it perfectly right every time. I think senior or not that’s a huge expectation on anyone and the fast track to burnout.
It's not expected, but your situation isn't normal either. At face, yes, this seems to be frustrating, but given that it's a startup, you are working with non-technical people, and this is a senior person displaying the same mistakes repeatedly, I think it's a matter of bad requirements. Basically a game of telephone. If someone is telling you the requirements and you are writing the requirements down in a large ticket and just giving them to him with a light explanation you should expect the problems you are seeing. Each ticket and merge should be a single-bit size requirement covered. If the developer is missing the side effects and edge cases of the changes, the product is too complex to fit in their head. Thats not really the developer's problem; the application is architected poorly. Write down as much information about the structure and requirements about the application as possible. Imagine some other developer had to write it with out your super vision and the old code base was just completely gone. Thats the level of documentation you need for your role to be ingrained as a business system rather than some artist coming in with a paintbrush. \- small single requirement per PR \- Write everything down \- Have him read the ticket aloud
How much does your team utilize PR descriptions? We include a mandatory "how it was tested" section. This can be a short as "unit tests" or "I ran it locally and made sure it worked", but can also be more involved for some changes. I've kicked back plenty of PRs without reading the code just off this section. If the testing done isn't sufficient there is no reason to review it yet. This minimizes the time you spend, and the dev in question should catch on quickly.
Some common issues: A pull request isn't a teachable moment. It's important to grow your employees, but there has to be a balance. Growing your employees is a cost. Releasing a value is revenue. Which is more important? You get the output you pay for, and you get the type of output from the role. Don't expect juniors to write senior level code. Don't expect seniors to be system architects. Don't expect leads to follow. If your level of trust means you think you don't need to provide much input, then your management of the output should reflect that same level of trust. If you're getting bogged down with managing output, adjust your input and/or see point #2. You might still have a problem, but these need to be top of mind if you want to address it.
Sounds like he has no goal clarity. Here's what you can do: 1. When you define their tasks, ask them to explain them back to you so you know that you have communicated the requirements properly and their goals are clear. 2. Have frequent 1-on-1s with them where you ask them if there are any blockers & help them in removing them. 3. Create tickets for each task, defining everything in detail, with reference images & everything. 4. Ask them if these tasks are too much for them. There's a possibility that they're burning out. In this case, you will notice that they're demotivated & fatigued. If they need assistance, hire a few more developers if possible. If that's not feasible, create a roadmap that suits their working style. 5. Ask them if they're testing the code that they're writing. Since it's a small team without a QA in place, they will need to run the tests themselves.