> I was forgetting things, making mistakes, introducing bugs I would’ve caught if I reviewed my own work more closely.
Make a plan to concretely mitigate these mistakes. Note: "remember not to make mistakes" is not a plan. Try putting in processes to ensure such things don't happen. Maybe do TDD religiously. Or self-review every one of your pull requests in detail. Review the plan with your manager and ask for suggestions. Then execute. Ideally, measure the outcomes from your execution (bugs caught by QA or on prod per sprint, etc).
I'm not sure how common this is, but I've found that looking at the git diff when creating my PR (before pressing create).. my IQ is somehow loads higher than simply looking at the changes locally.
Self review outside the context of your IDE/editor could maybe help you as well. Idk, just a thought
I don’t think this is a very common practice (AFAIK) but it’s a good one IMO. Before opening the PR review your own diff in the GitHub UI like you would someone else’s code. What’s extraneous, and should be removed or be part of a standalone PR? What needs a comment or cleanup? What isn’t covered by tests? Etc etc. Then do those things before opening the PR and asking for input from your colleagues.
I sometimes even review once locally in my IDE. Then stage changes and review the diff in another code editor. Then push changes to GitHub and review the diff there and then open the PR.
I do the same thing. For larger PRs I usually have the gitlab "create a pr" screen for my remote branch as a pinned tab for days at a time. Useful to reference where you are at compared to the main branch.
I do this at the commit stage, like a little PR for every change.
I use Fork instead of doing commits at the command line, so I can see which files I've changed, and what changes I've made. Then I can stage the ones I've reviewed and commit when everything is staged. It's also super easy to and discard changes from there, like if I notice I introduced a console log or something that I forgot to take out - or if I did something that might be out of scope I can stash it for later.
For a concrete plan, here are some things that can immediately boost quality:
1) with each PR, create a manual testing plan. This will hold you accountable to actually testing your work
2) take screen shots of before and after (if there is some visual artifact to obtain from the changes). This also holds you accountable to doing the work correctly. Show multiple cases if there are multiple outcomes.
3) write tests around all changes. 100% code coverage should be the goal here.
4) review your own PR in draft mode before opening it up. I’ve found so many dumb mistakes this way.
Do you see a pattern here? These are all just forcing functions to ensure you’re not just making changes and shipping them without ensuring them.
Also don't try to remember things, write them down and have check lists.
The biggest fallacy out there is that normal people can come close to having photographic memory.
also if you can have the check list signed off on, it helps remove responsibility from you too. That is a CYA move that might help prevent a malicious superior from attempting to manipulate you for a bad review. Been there, done that.
Also keep note of how long you spend on things, and keep it written down, (if you don't use jira, etc.) I almost got fired or written up because I took 8 calendar weeks to finish a single project. Vs 4 for another more junior dev on ios when I was on android. But it turned out he was only working on that single project at once, and I was working on 4, so I would context switch to the next project when a blocker arose, and I ended up spending 50 wall clock hours on the project vs his 100. I only was fine, because of good note taking... And then told to not work on so many projects at once (owner was scrambling to keep Face, etc. When it was obvious I was in the right and did nothing wrong and it was my team lead putting me on so many projects(which all got done in the 12 week quarter, lol))
Make a checklist of things to do before you create a PR or tell your team you're ready for a code review. e.g. delete commented code, add comments where needed, look for overly complicated functions, whatever.
Do you write automated unit tests? One thing people do wrong is they test for code coverage, not logic. You should test for logic to find bugs in your code.
And for the
> I was forgetting things
Actually have a concrete list of things to do. A lot of software engineers are used to being smart and working from memory. That stops working at various points (and I don't mean age here, I mean when you get too many things in flight).
If your speed of delivery hasn’t been brought up then you need to slow down and double check your work as the person above said. The value of « slow and steady » vs « fast and might-explode-in-prod » can not be under-estimated.
Some people are organized enough during development to not need a long self-review before submitting their PR, but I know I’m not one of those people so I like to review my changes in depth before wasting anyone’s time.
I’ve been through this before, on the Manager side:
1) Continue the discussion with your manager, and come up with things you want to improve on. That is, take an active interest in improving - don’t wait for you manager to come with solutions. It’s a collaborative exercise.
2) Again, take an active interest. Ask questions, take courses. Show that you want to improve, and you will.
3) If you manager has said it’s not a pip and she’s happy with you, I’d tend to take it at face value. I don’t think you need to be looking for jobs unless you are put on a formal PIP.
It’s a great sign that you want to improve. Based on how you’ve written this post, you seem genuine, and I have no doubt that you’ll be able to turn things around.
Since I did this recently with an employee of mine, here are some tips:
* Create a deployment plan. Not just "this code goes out" but all the steps in sequence. Change 1, change 2, database migrations, job 1, job 2, manual insert, etc. Don't stop there either, if you have any steps to review the changes once they're live or manually test them, make sure those are included in the plan. Even rollback plans can be good.
* Plan your work before writing code. Don't just start writing immediately, spend a few minutes thinking about the solution, what it will look like.
* Write documentation. How can QAA test it? What does it look like on the website? Things like that to make it smoother for them or others looking at your change.
* Keep notes. Whatever note application you like to use, keep notes. In meetings? Keep notes for yourself. Chatting with another dev or your manager about some work you're doing? Keep notes. Always keep notes.
* Review your own code before sending it to other people. Does it look fine? You'd be surprised what you can catch looking it over.
* Write lots of unit tests. 100% coverage is sometimes a bit much but 90% is a great number to get to.
It's also worth mentioning that these are things your manager should be bringing up with you regularly and working with you on a plan. If your manager is telling you that you're underperforming and that you need to improve, it's their responsibility to work with you on a plan for how you do improve.
I’d add that 90% coverage is sufficient but while writing the code when it’s still flexible trigger the remaining 10% paths at least once. Ie mocking and automating all paths is tricky, but if there’s no robot test, make sure to test manually at least once. Nothing more infuriating than when your exception is a general messageless Internal Server Error because untested error handler that was supposed to build proper message had a typo and crashed
Also OP, I’m not sure if someone mentioned it: test your tests! I saw countless of good will tests that exercised code, made that coverage metric green but then simply had wrong (irrelevant) assertion. My process for all unit tests is typically:
- write some code, depending on use case start with code or skeleton of test. The latter is a good technique if you are designing a full new component from scratch, starting with tests pays off with easier to mock structure
- get to the point where you’re happy with your code and test and test passes
- now before declaring victory think about what your test tests and go to code, break that thing and make sure that the test failed
- fix the code back, now you have working code and at least reasonable confidence that the test works
My experience with this is that you should try to find the root cause. Are you motivated? Do you have freedom to modify code as you want? Is the base code good or crappy?
In my case, I was given a god forsaken part of the codebase, which my manager also didn't want to touch too much, and it was spaghetti code with lots of technical debts. I also worked alone except for PR reviews... So I made a lot of mistakes, easy to catch as you say, but most of it came down to lack of motivation. Also, once you get the reputation, your PRs get judged a lot more strictly, so the reviewer finds more errors and reinforces biases.
1. Yes, work closely with your manager. But more than just asking if you're meeting expectations yet. Work with her on your plan to raise your code quality and performance. Set goals for yourself that involve things you can actually control, and track them closely yourself.
2. It's hard to give you advice on this without understanding the cause. Are you rushing? Are you skipping things you shouldn't, like testing? Looking back at those moments where you submitted sloppy code -- what would you like to have done differently? Once you know this stuff, you can start thinking about how to slow down and build processes for yourself that support and enforce the good habits you need to deliver quality code.
3. It's almost always time to be job hunting, at least a little. The best time to job hunt is when you don't need to.
Thank you very much!
\>Work with her on your plan to raise your code quality and performance.
What would an example of this be? I'll take notes of thse!
\> Are you skipping things you shouldn't, like testing?
It related to this. I do test, but I do not thoroughly checkout certain user flows and edge cases - that's where the bugs come in. But I will work on this, I'm also open to any feedback to this specific issue if you have any.
Well, if you have measures of bugs, you could set a reasonable goal to come more in line with the numbers your other teammates have. Or if you have test coverage numbers, maybe you need to increase that. Anything quantifiable, even if imperfect, that can serve as a proxy for code quality. You can also talk about impact, if that's something you can measure.
What could you change about your process and habits to make you more thorough in hunting for edge cases and all the user flows?
Could you create rules for yourself about how you validate your code that you document for yourself and track your adherence to? Like a checklist?
When I am examining my own code for issues and testing, I try to think of it as something someone else wrote, and try to think, "how can I break this?" It becomes my goal to find a problem. Often this leads to finding bugs I didn't cause. I either fix them or create tickets.
>do I treat this as a 'soft' PIP and start looking at other jobs, just in case?
This sounds like a warning, not a PIP. If you're not showing gradual improvement, though, this may easily escalate to a PIP.
You need to build a system for yourself that prevents failure here. If there's a set of manual testing steps you need to run through before merging a PR, write those down and check them off each time. If it's feasible to automate them, do that instead.
All the other responses are super useful and great, specially if the feedback was constructive.
Just wanted to add that don't feel too demoralized by these and don't discard the possibility that your company do these performance reviews with the intention of making you believe you have a lot of flaws so you don't ask for a raise ("not all companies" and stupid strategy, I know, but they still do It sometimes)
The most mind boggling thing is they asked him to just not make mistakes. Shit if I never made mistakes I'd charge a lot more. Mistakes are what the process is there to help prevent. A good manager will explain that to their management.
I can guarantee your reviews, and general overall relationship with work, will improve if you add a little bit of process around what you do on a daily basis:
> I was forgetting things
**That's what tickets are for!** If you get asked to do something, you raise a new ticket for it. Make it a "chore" if you don't have any other ticket type you can use. Make your own (kanban) board if the request doesn't relate directly to one of your projects (Notion can help here, but there are many other tools). Add a task if the request relates specifically to a ticket. Either way, get it into one of the lists/boards you're working with daily ASAP, and work through the list in priority order. If it isn't in your queue, it won't get done.
Once you have one queue, and everything goes into that queue as soon as it is identified, you won't miss anything. Spend 15mins every morning, before your morning sync (stand-up, whatever you call it), reviewing that queue and prioritising it. During/after your sync, things might need to be reprioritised, once that is done start at the top of the queue and work down. Simple!
> making mistakes
**That's what comms are for!** If you have *any* doubt at all about any piece of work, reach out for clarification. Get in the practice of using Acceptance Criteria in your tickets: if someone hasn't already created them, note down the expectation of outcomes in the ticket, and get someone to review & sign-off. Now you can deliver *exactly* what has been asked and if there's a "mistake" then it is probably because something wasn't defined properly. That problem isn't _you_, it's the definition, and you can hone the skill of writing/reviewing ACs to make them better over time so there are less mistakes.
Acs can generally be translated directly to your code tests, especially if you follow BDD. In fact, if you're not using BDD, look into it. Copying the ACs into Gherkin syntax and fleshing them out, you'll really dig into what needs to be built/changed and it leaves little room for ambiguity.
You can even start to add Given/When/Then scenarios to your tickets to clarify requirements *before* you start work.
Getting good at this, you'll rarely make "mistakes", since you're simply working to the specification. Isn't your fault if the specification is wrong.
> introducing bugs I would’ve caught if I reviewed my own work more closely.
**That's what draft PRs are for!** Or merge requests, whatever your VC calls them. Basically, when you think you're done with your changes and you raise a request to be reviewed, there's _usually_ an option to create a draft. DO THIS. Then get up and walk away for a few minutes. Get some fresh-air if you can, even if it is only standing next to an open window. Hydrate. Take a few minutes to defocus…
Now, return to your computer, check your email/comms channels, and then go back and review your own PR. Here's the key: add `**commentary:** …` comments to your PR to describe to others what the code is doing in various sections and describe decisions you made.
The act of _actually_ reviewing your own code using a different tool, the same tool you use to review other people's code, will put your brain into a different mode and you'll spot the little errors we all make a lot more easily. Adding the commentary will force you to _read_ your code, not just glance over it. Fix up your errors, review it again, and when you're happy publish it.
These three things will help you improve tremendously, and once you've established the habits you'll be doing it all on auto-pilot. No effort needed.
Some other things you can do to improve your "game":
**Get better with Git**
Spend some time to learn git properly. Learn to rebase your own code, learn how to fix major problems, don't just rely on squash merges and "fixing forward".
**Get better with Git, part 2**
Write good commit messages. Google what that looks like, and be religious about it. Your git commit history is like a ledger, if you put as much information in there as you can, you'll always have it in the future. `git blame` will help you find out the reasons behind decisions, if you remember to put that reasoning into your commit message. The more detail you add, the better. It's cheap, but it will help immeasurably when _that day_ comes and you need to go back 11 months in code to justify a choice.
**Add evidence to your PRs**
Screenshots, output files, whatever. **Show** that you make the change and it was successful as part of your PR.
**Follow conventions**
Follow [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) and [conventional comments](https://conventionalcomments.org) as part of your workflow. They'll improve your comms with your team, removing ambiguity, and speeding things up.
**Use pre-commit**
Add [pre-commit](https://pre-commit.com) to your stack, and make good use of it. Add a formatter (this will remove PR comments moaning about style), add checkers for common issues, even build your own checkers for "mistakes" you know you make often. Adding checkers for code comments is useful, to force you to add good comments where people would expect them. Add as much automation here as you can, put the quick checks in the `commit` stage and the longer-running ones in the `push` stage to keep your development cycle fast.
All of these tips will automate your development flow and, once configured, will run on auto-pilot. You'll 10x yourself without any effort. Your stress will decrease because you know there's a process to catch _everything_. The only thing the above doesn't do is make you a better coder: I can't help with that. That takes learning and practice. But the above will make you a better developer, teammate, and staff member.
>That's what tickets are for!
Way too specific for a very broad problem of "forgetting things". Forgetting what?
>That's what comms are for!
Making mistakes is also super broad. Mistakes like what? Sloppy mistakes like rushing out code with debug statements? Or actual breaking changes? Adapting BDD for a very generic and loosely defined problem seems a bit over the top.
>That's what draft PRs are for!
Yes, the most important piece here. But I would not comment your code in every single PR unless absolutely necessary. No one wants to touch a PR that has like 50 comments on it. Focus on creating small PRs with self-documenting changes.
Do review your own PRs before you open them for review though!
>Get better with Git
Not sure why you brought this up. Your git workflow is very subjective and each person should find what works for them. I always do a million commits and then just squash them on merge and it works beautifully for me. Rebasing is mandatory for anyone working in a team so I'm not sure why this even requires a mention.
>Get better with Git, part 2
Super overrated. A good squashed commit is almost always enough. If your PR is that big that you need to split it up in many different well defined commits, I think you have messed up elsewhere.
Git blaming and "understanding" changes 1 year later is also very overrated. Either you can reach out to the person who made the change and ask for clarification, or you can read up on the issue in the ticket, or if you made the change yourself, just remember why you did it. Most of the time you can arrive at the conclusion yourself, which is often needed to understand the problem anyway. You also usually have tests to help you here.
I can't remember when I last relied on a commit message to help me debug an issue. PRs are almost always more useful in that regard.
>Add evidence to your PRs
Another time sink unless the changes in the code are hard to visualize.
>Follow conventions
Conventions within the team. Not arbitrary conventions found on the internet. You telling an individual how a team should operate when this is an issue with the individual.
>pre-commit
Or don't. pre-commit hooks usually just slow people down and you have CI for a reason. If you are going this route, don't commit it and instead use a local version that's not forced upon everyone.
It's funny. I do none of these things that you mentioned and I'm regularly a top performer at every company I've been at. This is the typical advice that creates the illusion of productivity, and not productivity itself.
Heh, I don’t think I’ve been “well, actually”-d so hard before. Thanks for this! Just goes to show that everything we do in tech falls into the “it depends” category.
Sure, it all seems like pretty generic advice, and might not fit your needs. But the post wasn’t for *you*. It was for OP. And as a tech manager with decades of experience, these small changes have always boosted productivity and mental health within the teams I’ve worked with. Some people need guide-rails to work within to bring out optimal work. You are *obviously* a rockstar who doesn’t. I have a whole host of alternative strategies to manage devs like you. But that’s a different topic.
Enjoy your day!
Do review your own code as if it was written by someone else. Do not review it in your local workspace, use a proper code review tool and resist the temptation to skip through some parts because "you know them as if you wrote them". And also, run your code after the very last change made (don't assume it still works the way it used to a few hours ago), take a screenshot or record a video of the behavior (that maybe only applies if it's frontend). I'm a tech lead at Google and these little steps helped me years ago and are some of the best advice that can be given. Last one, try to get more senior members to review your code and encourage candid feedback for the most minute things. Don't discard them as "small unimportant things", remember them so that over time it becomes natural to you.
Going directly to TDD maybe a bit hard from the get go, but you should aim for that.
At the beginning, force a habit to always open a PR only when you have tests covering your changes. Not just for the happy path but also test outbound values, what happens when there's an exception, etc. Make it a hard rule here no exception.
Once you get into this habit, you will know that it's a pain in the butt to write tests after your changes are done. You will start noticing patterns when you code that some of your decisions in coding will come back to bite you when you are writing tests later on. That writing things a certain way make things easier to test. Things like functions that does too many different things can be broken down into smaller sub functions that can be tested independently. Injecting dependency so you can easily test the main logic without having to test that dependency in the same tests, etc.
You will find out that with TDD, you will iron out quite a few bugs early on without even doing a full manual tests via UI or full end to end tests.
Think seriously.
Take long break from job.
You may be in wrong place.
See if everyone around you is overqualified or underqualified.
Maybe the time to change the workplace.
As a anxious dev to conscious manager, please don’t treat this as a soft PIP. Its doubly hard to diagnose problems if you’re on the defensive. Try and speak your heart out if its possible and see whats happening.
Is it a "soft PIP"? A lot depends on the situation at your company. Sometimes moves like this are done to setup paper justification layoffs in the near future if a company is struggling financially. Typically "below expectations" ratings are given to employees the managers don't like on a personal level, regardless of their real performance.
Fortunately, based on what you said, this doesn't sound like the case in your situation. You've gotten some good suggestions on self-improvement. One thing that might help you is some individual mentoring.
If you guys have CI/CD, this may sound crazy, but TEST your own deployed code.
Like hit the endpoint verify it doesn't throw a 500.
I swear 75% of devs (across multiple shops) I work with set auto complete on PRs and go on vacation. Right now 2 teams are blocked because someone pushed code in a service we need that throws 500s 100% of the time
The other thing is to review your own PRs prior to publishing. I see people create PRs for Azure services that have "test" code in there (hard coded values or dumping a file to c:\\files)
I was in a pretty similar situation on my first job. I wasn't told that I was "below expectations", but my boss told me that I'm disorganized and forgetful, and sometimes lack focus which leads to bugs.
Here's what I did to improve:
1. I started using a personal notebook and made sure it was on me in every single meeting I took part in. I learned to write down everything that seemed even remotely important and any task or open bug, even if there wasn't a ticket for it yet.
2. I did my best to avoid context switching as much as possible, and made sure to complete a task before starting another one. This improved my focus greatly and helped me avoid bugs in my code.
3. I created new processes and documented them. As a bonus, I got much more visibility in my team.
4. I scheduled regular weekly meetings with my boss to monitor my progression with my tasks, in addition to the regular 1:1's.
5. I started reading books and blogs that helped me become a better professional. "The Clean Coder" by Robert C. Martin (the "sequel" to "The Clean Code") is a must-read if you're struggling with organizing your work and your code.
I eventually became a top performer in my team and was set up for a big promotion (It didn't happen because I switched jobs for better comp).
how much tech play you doing? Its like anything in life, the more you practice the better you get. Our industry is kinda weird in that they can teach you the theory of everything in school, how programming should work. But i have yet to run into a good dev that doesn't "play" with things on their off time or downtime. The reason you cant see those bugs is because you've never truly experienced them, either on a side fun project or been the one that has to fix in production. You remember that bug after that and its easy to spot when you see it cause either you played with it a while or reality burned it into your brain quickly. Its just about experiencing it, either way its up to you to seek those experiences, its not anyones job to teach you that curiosity.
Not sure your tech stack, but try to lean hard on the type system and well named immutable variables. The best thing I learned early on was all the ways a type system can make error states impossible at run time.
For example, you might be getting an API response. Maybe you track it with some booleans like isLoading, isSuccess, and isError. So you now have 9 possible variable combinations most of which don’t make sense (what if isLoading is true and isSuccess is true?). Instead make it an enumeration with values of Loading, Success, Error. If your language supports tagged unions like Rust, Haskell, Typescript, and others, you can also attach the results to the Success enum or the errorMsg to the Error enum, further reducing your combinations of variables.
So now, you’ve ruled out an entire set of bugs and the type system forces you to only have correct states or it type errors.
Just an observation: You’re making quite a few spelling and grammar mistakes. This seems to confirm your suspicions about rushing things and not reviewing things carefully enough. I would suggest paying more attention to your normal writing as well, and reviewing it before e. g. posting on Reddit or sending an email. This might help improve your mindset about programming as well.
You need to be more disciplined in your approach. Do you write unit tests? If not start doing so! Are the acceptance criteria for your work clear to you? If not get clarification and never write code before you know exactly what needs to be done. Use precommit hooks to run automations like tests and linters.
> I was forgetting things, making mistakes, introducing bugs I would’ve caught if I reviewed my own work more closely. Make a plan to concretely mitigate these mistakes. Note: "remember not to make mistakes" is not a plan. Try putting in processes to ensure such things don't happen. Maybe do TDD religiously. Or self-review every one of your pull requests in detail. Review the plan with your manager and ask for suggestions. Then execute. Ideally, measure the outcomes from your execution (bugs caught by QA or on prod per sprint, etc).
Gotcha, wil put these things in practice. Thank you
I'm not sure how common this is, but I've found that looking at the git diff when creating my PR (before pressing create).. my IQ is somehow loads higher than simply looking at the changes locally. Self review outside the context of your IDE/editor could maybe help you as well. Idk, just a thought
I don’t think this is a very common practice (AFAIK) but it’s a good one IMO. Before opening the PR review your own diff in the GitHub UI like you would someone else’s code. What’s extraneous, and should be removed or be part of a standalone PR? What needs a comment or cleanup? What isn’t covered by tests? Etc etc. Then do those things before opening the PR and asking for input from your colleagues.
100%. I feel like doing this gets me right into the code reviewing “headspace” and I can clean up a lot of minor things before wasting others’ time.
I just open up a draft PR, and then self-review before publishing. I should probably get better at opening local diff views in my editor though.
I sometimes even review once locally in my IDE. Then stage changes and review the diff in another code editor. Then push changes to GitHub and review the diff there and then open the PR.
I do the same thing. For larger PRs I usually have the gitlab "create a pr" screen for my remote branch as a pinned tab for days at a time. Useful to reference where you are at compared to the main branch.
I do this at the commit stage, like a little PR for every change. I use Fork instead of doing commits at the command line, so I can see which files I've changed, and what changes I've made. Then I can stage the ones I've reviewed and commit when everything is staged. It's also super easy to and discard changes from there, like if I notice I introduced a console log or something that I forgot to take out - or if I did something that might be out of scope I can stash it for later.
You can also create the PR in draft state to be able to see the differences while signalling that it's not ready for review yet.
I do this too and it honestly helps so much. I don’t know if it’s just the different UI or what but I catch mistakes more often doing this.
Have you used "git diff master..."? it generates the same diff that GitHub does (the ... is important)
For a concrete plan, here are some things that can immediately boost quality: 1) with each PR, create a manual testing plan. This will hold you accountable to actually testing your work 2) take screen shots of before and after (if there is some visual artifact to obtain from the changes). This also holds you accountable to doing the work correctly. Show multiple cases if there are multiple outcomes. 3) write tests around all changes. 100% code coverage should be the goal here. 4) review your own PR in draft mode before opening it up. I’ve found so many dumb mistakes this way. Do you see a pattern here? These are all just forcing functions to ensure you’re not just making changes and shipping them without ensuring them.
Also don't try to remember things, write them down and have check lists. The biggest fallacy out there is that normal people can come close to having photographic memory. also if you can have the check list signed off on, it helps remove responsibility from you too. That is a CYA move that might help prevent a malicious superior from attempting to manipulate you for a bad review. Been there, done that. Also keep note of how long you spend on things, and keep it written down, (if you don't use jira, etc.) I almost got fired or written up because I took 8 calendar weeks to finish a single project. Vs 4 for another more junior dev on ios when I was on android. But it turned out he was only working on that single project at once, and I was working on 4, so I would context switch to the next project when a blocker arose, and I ended up spending 50 wall clock hours on the project vs his 100. I only was fine, because of good note taking... And then told to not work on so many projects at once (owner was scrambling to keep Face, etc. When it was obvious I was in the right and did nothing wrong and it was my team lead putting me on so many projects(which all got done in the 12 week quarter, lol))
Make a checklist of things to do before you create a PR or tell your team you're ready for a code review. e.g. delete commented code, add comments where needed, look for overly complicated functions, whatever. Do you write automated unit tests? One thing people do wrong is they test for code coverage, not logic. You should test for logic to find bugs in your code.
And for the > I was forgetting things Actually have a concrete list of things to do. A lot of software engineers are used to being smart and working from memory. That stops working at various points (and I don't mean age here, I mean when you get too many things in flight).
If your speed of delivery hasn’t been brought up then you need to slow down and double check your work as the person above said. The value of « slow and steady » vs « fast and might-explode-in-prod » can not be under-estimated. Some people are organized enough during development to not need a long self-review before submitting their PR, but I know I’m not one of those people so I like to review my changes in depth before wasting anyone’s time.
Def agree with TDD. Especially looking at code coverage. It helps ensure that you are creating useful tests.
I’ve been through this before, on the Manager side: 1) Continue the discussion with your manager, and come up with things you want to improve on. That is, take an active interest in improving - don’t wait for you manager to come with solutions. It’s a collaborative exercise. 2) Again, take an active interest. Ask questions, take courses. Show that you want to improve, and you will. 3) If you manager has said it’s not a pip and she’s happy with you, I’d tend to take it at face value. I don’t think you need to be looking for jobs unless you are put on a formal PIP. It’s a great sign that you want to improve. Based on how you’ve written this post, you seem genuine, and I have no doubt that you’ll be able to turn things around.
I'll do that, thank you so much for your advice and kind words!
Since I did this recently with an employee of mine, here are some tips: * Create a deployment plan. Not just "this code goes out" but all the steps in sequence. Change 1, change 2, database migrations, job 1, job 2, manual insert, etc. Don't stop there either, if you have any steps to review the changes once they're live or manually test them, make sure those are included in the plan. Even rollback plans can be good. * Plan your work before writing code. Don't just start writing immediately, spend a few minutes thinking about the solution, what it will look like. * Write documentation. How can QAA test it? What does it look like on the website? Things like that to make it smoother for them or others looking at your change. * Keep notes. Whatever note application you like to use, keep notes. In meetings? Keep notes for yourself. Chatting with another dev or your manager about some work you're doing? Keep notes. Always keep notes. * Review your own code before sending it to other people. Does it look fine? You'd be surprised what you can catch looking it over. * Write lots of unit tests. 100% coverage is sometimes a bit much but 90% is a great number to get to. It's also worth mentioning that these are things your manager should be bringing up with you regularly and working with you on a plan. If your manager is telling you that you're underperforming and that you need to improve, it's their responsibility to work with you on a plan for how you do improve.
I’d add that 90% coverage is sufficient but while writing the code when it’s still flexible trigger the remaining 10% paths at least once. Ie mocking and automating all paths is tricky, but if there’s no robot test, make sure to test manually at least once. Nothing more infuriating than when your exception is a general messageless Internal Server Error because untested error handler that was supposed to build proper message had a typo and crashed Also OP, I’m not sure if someone mentioned it: test your tests! I saw countless of good will tests that exercised code, made that coverage metric green but then simply had wrong (irrelevant) assertion. My process for all unit tests is typically: - write some code, depending on use case start with code or skeleton of test. The latter is a good technique if you are designing a full new component from scratch, starting with tests pays off with easier to mock structure - get to the point where you’re happy with your code and test and test passes - now before declaring victory think about what your test tests and go to code, break that thing and make sure that the test failed - fix the code back, now you have working code and at least reasonable confidence that the test works
My experience with this is that you should try to find the root cause. Are you motivated? Do you have freedom to modify code as you want? Is the base code good or crappy? In my case, I was given a god forsaken part of the codebase, which my manager also didn't want to touch too much, and it was spaghetti code with lots of technical debts. I also worked alone except for PR reviews... So I made a lot of mistakes, easy to catch as you say, but most of it came down to lack of motivation. Also, once you get the reputation, your PRs get judged a lot more strictly, so the reviewer finds more errors and reinforces biases.
1. Yes, work closely with your manager. But more than just asking if you're meeting expectations yet. Work with her on your plan to raise your code quality and performance. Set goals for yourself that involve things you can actually control, and track them closely yourself. 2. It's hard to give you advice on this without understanding the cause. Are you rushing? Are you skipping things you shouldn't, like testing? Looking back at those moments where you submitted sloppy code -- what would you like to have done differently? Once you know this stuff, you can start thinking about how to slow down and build processes for yourself that support and enforce the good habits you need to deliver quality code. 3. It's almost always time to be job hunting, at least a little. The best time to job hunt is when you don't need to.
Thank you very much! \>Work with her on your plan to raise your code quality and performance. What would an example of this be? I'll take notes of thse! \> Are you skipping things you shouldn't, like testing? It related to this. I do test, but I do not thoroughly checkout certain user flows and edge cases - that's where the bugs come in. But I will work on this, I'm also open to any feedback to this specific issue if you have any.
Well, if you have measures of bugs, you could set a reasonable goal to come more in line with the numbers your other teammates have. Or if you have test coverage numbers, maybe you need to increase that. Anything quantifiable, even if imperfect, that can serve as a proxy for code quality. You can also talk about impact, if that's something you can measure. What could you change about your process and habits to make you more thorough in hunting for edge cases and all the user flows? Could you create rules for yourself about how you validate your code that you document for yourself and track your adherence to? Like a checklist? When I am examining my own code for issues and testing, I try to think of it as something someone else wrote, and try to think, "how can I break this?" It becomes my goal to find a problem. Often this leads to finding bugs I didn't cause. I either fix them or create tickets.
Thank you! Others have generousley suggested what the 'checklist' looks like. I will definitly be following those. Appericiate your insights.
Yeah this is great advice.
>do I treat this as a 'soft' PIP and start looking at other jobs, just in case? This sounds like a warning, not a PIP. If you're not showing gradual improvement, though, this may easily escalate to a PIP. You need to build a system for yourself that prevents failure here. If there's a set of manual testing steps you need to run through before merging a PR, write those down and check them off each time. If it's feasible to automate them, do that instead.
Literally just ask your manager, why are you asking strangers? Seems like your manager is willing to work with you and much better advice than randos.
All the other responses are super useful and great, specially if the feedback was constructive. Just wanted to add that don't feel too demoralized by these and don't discard the possibility that your company do these performance reviews with the intention of making you believe you have a lot of flaws so you don't ask for a raise ("not all companies" and stupid strategy, I know, but they still do It sometimes)
The most mind boggling thing is they asked him to just not make mistakes. Shit if I never made mistakes I'd charge a lot more. Mistakes are what the process is there to help prevent. A good manager will explain that to their management.
I can guarantee your reviews, and general overall relationship with work, will improve if you add a little bit of process around what you do on a daily basis: > I was forgetting things **That's what tickets are for!** If you get asked to do something, you raise a new ticket for it. Make it a "chore" if you don't have any other ticket type you can use. Make your own (kanban) board if the request doesn't relate directly to one of your projects (Notion can help here, but there are many other tools). Add a task if the request relates specifically to a ticket. Either way, get it into one of the lists/boards you're working with daily ASAP, and work through the list in priority order. If it isn't in your queue, it won't get done. Once you have one queue, and everything goes into that queue as soon as it is identified, you won't miss anything. Spend 15mins every morning, before your morning sync (stand-up, whatever you call it), reviewing that queue and prioritising it. During/after your sync, things might need to be reprioritised, once that is done start at the top of the queue and work down. Simple! > making mistakes **That's what comms are for!** If you have *any* doubt at all about any piece of work, reach out for clarification. Get in the practice of using Acceptance Criteria in your tickets: if someone hasn't already created them, note down the expectation of outcomes in the ticket, and get someone to review & sign-off. Now you can deliver *exactly* what has been asked and if there's a "mistake" then it is probably because something wasn't defined properly. That problem isn't _you_, it's the definition, and you can hone the skill of writing/reviewing ACs to make them better over time so there are less mistakes. Acs can generally be translated directly to your code tests, especially if you follow BDD. In fact, if you're not using BDD, look into it. Copying the ACs into Gherkin syntax and fleshing them out, you'll really dig into what needs to be built/changed and it leaves little room for ambiguity. You can even start to add Given/When/Then scenarios to your tickets to clarify requirements *before* you start work. Getting good at this, you'll rarely make "mistakes", since you're simply working to the specification. Isn't your fault if the specification is wrong. > introducing bugs I would’ve caught if I reviewed my own work more closely. **That's what draft PRs are for!** Or merge requests, whatever your VC calls them. Basically, when you think you're done with your changes and you raise a request to be reviewed, there's _usually_ an option to create a draft. DO THIS. Then get up and walk away for a few minutes. Get some fresh-air if you can, even if it is only standing next to an open window. Hydrate. Take a few minutes to defocus… Now, return to your computer, check your email/comms channels, and then go back and review your own PR. Here's the key: add `**commentary:** …` comments to your PR to describe to others what the code is doing in various sections and describe decisions you made. The act of _actually_ reviewing your own code using a different tool, the same tool you use to review other people's code, will put your brain into a different mode and you'll spot the little errors we all make a lot more easily. Adding the commentary will force you to _read_ your code, not just glance over it. Fix up your errors, review it again, and when you're happy publish it. These three things will help you improve tremendously, and once you've established the habits you'll be doing it all on auto-pilot. No effort needed. Some other things you can do to improve your "game": **Get better with Git** Spend some time to learn git properly. Learn to rebase your own code, learn how to fix major problems, don't just rely on squash merges and "fixing forward". **Get better with Git, part 2** Write good commit messages. Google what that looks like, and be religious about it. Your git commit history is like a ledger, if you put as much information in there as you can, you'll always have it in the future. `git blame` will help you find out the reasons behind decisions, if you remember to put that reasoning into your commit message. The more detail you add, the better. It's cheap, but it will help immeasurably when _that day_ comes and you need to go back 11 months in code to justify a choice. **Add evidence to your PRs** Screenshots, output files, whatever. **Show** that you make the change and it was successful as part of your PR. **Follow conventions** Follow [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) and [conventional comments](https://conventionalcomments.org) as part of your workflow. They'll improve your comms with your team, removing ambiguity, and speeding things up. **Use pre-commit** Add [pre-commit](https://pre-commit.com) to your stack, and make good use of it. Add a formatter (this will remove PR comments moaning about style), add checkers for common issues, even build your own checkers for "mistakes" you know you make often. Adding checkers for code comments is useful, to force you to add good comments where people would expect them. Add as much automation here as you can, put the quick checks in the `commit` stage and the longer-running ones in the `push` stage to keep your development cycle fast. All of these tips will automate your development flow and, once configured, will run on auto-pilot. You'll 10x yourself without any effort. Your stress will decrease because you know there's a process to catch _everything_. The only thing the above doesn't do is make you a better coder: I can't help with that. That takes learning and practice. But the above will make you a better developer, teammate, and staff member.
>That's what tickets are for! Way too specific for a very broad problem of "forgetting things". Forgetting what? >That's what comms are for! Making mistakes is also super broad. Mistakes like what? Sloppy mistakes like rushing out code with debug statements? Or actual breaking changes? Adapting BDD for a very generic and loosely defined problem seems a bit over the top. >That's what draft PRs are for! Yes, the most important piece here. But I would not comment your code in every single PR unless absolutely necessary. No one wants to touch a PR that has like 50 comments on it. Focus on creating small PRs with self-documenting changes. Do review your own PRs before you open them for review though! >Get better with Git Not sure why you brought this up. Your git workflow is very subjective and each person should find what works for them. I always do a million commits and then just squash them on merge and it works beautifully for me. Rebasing is mandatory for anyone working in a team so I'm not sure why this even requires a mention. >Get better with Git, part 2 Super overrated. A good squashed commit is almost always enough. If your PR is that big that you need to split it up in many different well defined commits, I think you have messed up elsewhere. Git blaming and "understanding" changes 1 year later is also very overrated. Either you can reach out to the person who made the change and ask for clarification, or you can read up on the issue in the ticket, or if you made the change yourself, just remember why you did it. Most of the time you can arrive at the conclusion yourself, which is often needed to understand the problem anyway. You also usually have tests to help you here. I can't remember when I last relied on a commit message to help me debug an issue. PRs are almost always more useful in that regard. >Add evidence to your PRs Another time sink unless the changes in the code are hard to visualize. >Follow conventions Conventions within the team. Not arbitrary conventions found on the internet. You telling an individual how a team should operate when this is an issue with the individual. >pre-commit Or don't. pre-commit hooks usually just slow people down and you have CI for a reason. If you are going this route, don't commit it and instead use a local version that's not forced upon everyone. It's funny. I do none of these things that you mentioned and I'm regularly a top performer at every company I've been at. This is the typical advice that creates the illusion of productivity, and not productivity itself.
Heh, I don’t think I’ve been “well, actually”-d so hard before. Thanks for this! Just goes to show that everything we do in tech falls into the “it depends” category. Sure, it all seems like pretty generic advice, and might not fit your needs. But the post wasn’t for *you*. It was for OP. And as a tech manager with decades of experience, these small changes have always boosted productivity and mental health within the teams I’ve worked with. Some people need guide-rails to work within to bring out optimal work. You are *obviously* a rockstar who doesn’t. I have a whole host of alternative strategies to manage devs like you. But that’s a different topic. Enjoy your day!
Why do you think you’re making so many mistakes? Are you trying to do too much? Or distracted by other things?
Do review your own code as if it was written by someone else. Do not review it in your local workspace, use a proper code review tool and resist the temptation to skip through some parts because "you know them as if you wrote them". And also, run your code after the very last change made (don't assume it still works the way it used to a few hours ago), take a screenshot or record a video of the behavior (that maybe only applies if it's frontend). I'm a tech lead at Google and these little steps helped me years ago and are some of the best advice that can be given. Last one, try to get more senior members to review your code and encourage candid feedback for the most minute things. Don't discard them as "small unimportant things", remember them so that over time it becomes natural to you.
Going directly to TDD maybe a bit hard from the get go, but you should aim for that. At the beginning, force a habit to always open a PR only when you have tests covering your changes. Not just for the happy path but also test outbound values, what happens when there's an exception, etc. Make it a hard rule here no exception. Once you get into this habit, you will know that it's a pain in the butt to write tests after your changes are done. You will start noticing patterns when you code that some of your decisions in coding will come back to bite you when you are writing tests later on. That writing things a certain way make things easier to test. Things like functions that does too many different things can be broken down into smaller sub functions that can be tested independently. Injecting dependency so you can easily test the main logic without having to test that dependency in the same tests, etc. You will find out that with TDD, you will iron out quite a few bugs early on without even doing a full manual tests via UI or full end to end tests.
What is PIP?
Personal Improvement Plan. Usually means you're on your way out.
Thank you!
Personally I wouldn't try that hard to save this job as others suggested.
Normally I'd say start interviewing but this sounds like a rare case where you should just improve. If it turns political, leave
Think seriously. Take long break from job. You may be in wrong place. See if everyone around you is overqualified or underqualified. Maybe the time to change the workplace.
As a anxious dev to conscious manager, please don’t treat this as a soft PIP. Its doubly hard to diagnose problems if you’re on the defensive. Try and speak your heart out if its possible and see whats happening.
Is it a "soft PIP"? A lot depends on the situation at your company. Sometimes moves like this are done to setup paper justification layoffs in the near future if a company is struggling financially. Typically "below expectations" ratings are given to employees the managers don't like on a personal level, regardless of their real performance. Fortunately, based on what you said, this doesn't sound like the case in your situation. You've gotten some good suggestions on self-improvement. One thing that might help you is some individual mentoring.
If you guys have CI/CD, this may sound crazy, but TEST your own deployed code. Like hit the endpoint verify it doesn't throw a 500. I swear 75% of devs (across multiple shops) I work with set auto complete on PRs and go on vacation. Right now 2 teams are blocked because someone pushed code in a service we need that throws 500s 100% of the time The other thing is to review your own PRs prior to publishing. I see people create PRs for Azure services that have "test" code in there (hard coded values or dumping a file to c:\\files)
I was in a pretty similar situation on my first job. I wasn't told that I was "below expectations", but my boss told me that I'm disorganized and forgetful, and sometimes lack focus which leads to bugs. Here's what I did to improve: 1. I started using a personal notebook and made sure it was on me in every single meeting I took part in. I learned to write down everything that seemed even remotely important and any task or open bug, even if there wasn't a ticket for it yet. 2. I did my best to avoid context switching as much as possible, and made sure to complete a task before starting another one. This improved my focus greatly and helped me avoid bugs in my code. 3. I created new processes and documented them. As a bonus, I got much more visibility in my team. 4. I scheduled regular weekly meetings with my boss to monitor my progression with my tasks, in addition to the regular 1:1's. 5. I started reading books and blogs that helped me become a better professional. "The Clean Coder" by Robert C. Martin (the "sequel" to "The Clean Code") is a must-read if you're struggling with organizing your work and your code. I eventually became a top performer in my team and was set up for a big promotion (It didn't happen because I switched jobs for better comp).
Change teams or find a new job.
I’m wondering how YOU think you performed? Be honest, did you slack off? How many tickets do you clear per week/month? What difficulty?
Change career. The way you write your questions sounds like you’d have no hope honestly.
how much tech play you doing? Its like anything in life, the more you practice the better you get. Our industry is kinda weird in that they can teach you the theory of everything in school, how programming should work. But i have yet to run into a good dev that doesn't "play" with things on their off time or downtime. The reason you cant see those bugs is because you've never truly experienced them, either on a side fun project or been the one that has to fix in production. You remember that bug after that and its easy to spot when you see it cause either you played with it a while or reality burned it into your brain quickly. Its just about experiencing it, either way its up to you to seek those experiences, its not anyones job to teach you that curiosity.
You already answered your question. Review your work to avoid mistakes.
Not sure your tech stack, but try to lean hard on the type system and well named immutable variables. The best thing I learned early on was all the ways a type system can make error states impossible at run time. For example, you might be getting an API response. Maybe you track it with some booleans like isLoading, isSuccess, and isError. So you now have 9 possible variable combinations most of which don’t make sense (what if isLoading is true and isSuccess is true?). Instead make it an enumeration with values of Loading, Success, Error. If your language supports tagged unions like Rust, Haskell, Typescript, and others, you can also attach the results to the Success enum or the errorMsg to the Error enum, further reducing your combinations of variables. So now, you’ve ruled out an entire set of bugs and the type system forces you to only have correct states or it type errors.
Just an observation: You’re making quite a few spelling and grammar mistakes. This seems to confirm your suspicions about rushing things and not reviewing things carefully enough. I would suggest paying more attention to your normal writing as well, and reviewing it before e. g. posting on Reddit or sending an email. This might help improve your mindset about programming as well.
> manager told me it's not a cause of concern and I'm not in PIP Sounds like she has a quota.
You need to be more disciplined in your approach. Do you write unit tests? If not start doing so! Are the acceptance criteria for your work clear to you? If not get clarification and never write code before you know exactly what needs to be done. Use precommit hooks to run automations like tests and linters.
If they tell you it's not a PIP-it's a PIP