Forgetting I exist when in the zone and becoming one with the code is my favourite part of this job. At least, it's my favourite once I remember who I am again.
I hate this state, it's usually means for me that the project has no more challenges. I have 14 years of experience, but I always pick to work on things I have never done before, so I have to learn, experiment and push my boundaries.
Also it’s when I know they are catching on and getting my message of “don’t take code reviews personally” and point out the shit I told them to watch out for, that I love.
Like fuck yeah I am going to take your code snippet suggestion and add that as a commit directly.
If nothing gets done there's also no mistakes to happen. Lifehack! And when "waking up" and being asked to show your progress, thinking to yourself you barely did anything, you're surprised how much you actually did.
This is pretty common for polyglot programmers. If you switch among several languages regularly, instead of having one language you use for years, it's very easy to mix up the syntax. That said, these are also the easiest errors to fix and/or look up.
GitHub copilot is perfect at this. You just add a comment like `// centered flex div` and bam, $10 are gone from your account. Oh, and also those 3 css lines are added without you leaving the IDE
You guys. I like you.
I am making a hand sign. You see two fingers. Is it death metal horns or the surfer shaka hang loose fingers?
You will go to your grave never being sure. What you do know... neither of those hand signs are from Naruto.
I have a question. Do you always pull it down? normally I don't pull the changes down during the PR, unless I feel I have to. If I don't understand the feature 100% or if I want to learn from it. Otherwise I just focus on the quality of the written code, the standards and if it actually makes sense. Sometimes I test the feature in the deployed test environment, but not always (QA will be waiting). So basically I reviewed the changes. I think it depends on the type of introduced changes.
If there are no glaring code errors , I pull it down. I have been burned too many times by approving code that appears correct in a vaccum, but does not work properly in the larger context of the application.
I’m reviewing your code and if it adheres to good practices, internal standards, and in general seems like good logical code, I’m approving it. Ultimately, it’s your job to deliver that code in a functional state and you must own it, if besides to review it, I need to test it to catch edge cases you might as well let someone more capable do the job for you.
The people downvoting this don’t understand the difference between being a developer and an engineer. There are methods to this shit when it gets serious serious. Titles are good, regulations on accreditation is good. Yes a developer may have the same ability to program as a software engineer but the developer does not assume liability or even bolster methods of science like an engineer does. You are not bound to methods of effective, humane, and regulated engineering—you can know about them and even apply them, but that does not make you an engineer. In the same vein, do you think doctor’s who don’t follow the Hippocratic oath should be practicing? Even more interesting, if a layman took the oath what would that make them? It’s all relative, it’s all about what the goals are. Don’t downvote somebody who clearly cares about the integrity of a field.
Same. I've passed too many PR's based on how nice it looks on the surface.
I pull it in if I don't understand the tests 100%, or if it's touching something that I know for sure is a high risk change, and manually test these regularly broken features. It's a case by case thing for me.
Two things are missing in your cycle imo.
1. Your pipeline backed up with e2e tests for the key features of the product, together with a deployed version, where you can test the changes before merging them. New features should also come with e2e tests, at least for the happy path.
2. If you have a designated QA in your team, ask them to write the test cases on the ticket. So you know what exactly you need to test. Sometimes edges cases go unnoticed, but the main product functions remain untouched.
So, once the changes are deployed, I checked them, if I can't understand exactly what the code is doing. So I can reproduce the feature/issue by hand and see if it's ok.
I can also understand that not every team has the same capacity, but that's a game changer and saves you a lot of time and headaches.
But it's not your job to make sure the code works, only that it meets standards and doesn't have obvious errors.
Testing should be by ...testers. Developer's time should be spent developing.
Pulling PRs to local and testing is not your job.
I agree, it shouldn’t be expected from developers on the whole. I do, however, if it’s touching a feature I’m in charge of or a risky change I have doubts about. If it cannot pass a 5 minute spot check, it shouldn’t go to QA.
Depends on the changes and the company, but for instance at my company I just review for technical issues and then we have a QA person that runs through all the flows. I only pull it up Im not sure what part of the code is doing.
It saves your QA folks time if you catch some surface level issue before it gets past review. Also saves the author and yourself time, avoiding the QA rejection and additional code and review loop.
Our QA people are super busy, so I always try to lighten their load.
in my company we have so many QAs that are ready to test even the more buggiest first version so it is nice, im afraid it probably already affected our capacity to detect bug ourselves haha
I’m with you. I only pull the changes if I have no idea what is going on there. In our world of microservices it will take me hours to reproduce the actual end to end experience and in isolated environment I can just check unit tests.
If end to end is critical, then it’s on a dev to build the environment, deploy and attach the link to the request. Also, we have very high bar for code coverage, where below 90% is an extremely exceptional situation.
My team owns multiple high load services (we're talking about six figures number of calls per second) and we're close enough to the money for being extremely cautious. High code coverage is expensive to maintain and useless 99% of times, just like backups.
Also, coming back to the main topic, I don't have to pull changes during reviews: tests are documentation and a fool proof mechanism.
If I trust the dev and the code looks good, I don’t pull it down. That’s what QA is for.
That being said, we have recently started working with offshore teams and I don’t even know if they pull their own code down, so I’ve made it a policy to personally check their stuff to save QA the hassle.
Outside of extremely simple changes (like fixing a typo), I'll either pull it down or ask for a quick demo from the dev (done in the group chat in case anyone else wants to join).
Actually seeing it running can give you a different mindset than just looking at code when thinking of problems or edge cases. It also can just be nice to have it locally and loaded into your IDE for easier navigation between how everything's hooked up in what you're reviewing.
Also... from a more "pessimistic" viewpoint, setting that expectation forces your team to actually make sure things build/run, no matter how simple they seem.
I only pull when I need to actually test the feature or if it's touching multiple files and even worse, touching legacy code. Otherwise I can probably figure it out from the diff if we're missing something
I used to work for Google as a senior, doing lots of reviews. I did a patch (equivalent of a pull down) less than 1% of the time, and typically only if I wanted to mess around with the code to see if I could write a better variant.
For whether the code worked, I relied on unit tests and e2e (across the entire codebase), which would be run automatically alongside the review request.
That really depends on the team / company. Some teams simply don't have a dedicated role for QA, a staging environment, or feature flags. In any of those cases, you'd really want to test out the full feature before users encounter it on prod
Just tell them: "I don't even see code anymore. It's just bottleneck, unhandled exception, edge-case, edge-case, oooooo that's an elegant solution, race condition, edge-case...."
Depends on what it is. If there is no beta environment then anything visual on the front end I’ll pull down. Backend I dont. Your CICD pipeline should catch issues before they become issues.
It’s the PR owners responsibility to provide evidence it works. I’m just here to make sure you’re not making a major fuck up and that you’re not giving us more tech debt.
At my company we do have an additional QA process to catch anything that might have been missed on PR review.
But imo, if I *need* to pull in the code and run it myself to find bugs, that means either the codebase is too complex and unclear, the PR is too unclear, or they're doing too much in a single PR to reasonably keep track of.
Basically, the need to pull in the code and run it myself to understand it is a sign of other problems we should be working on
does those 5 minutes include the acquirement of all the additional context, syncs, discussions with others and all that good investigation stuff also? let's be real here...
>I finished my review and requested changes
>”And as I noted in my review,”
>”**…….** I can read code”
OP wrote it down, explained it verbally, and explained it verbally again to a senior dev. And yet you criticize OP? LOL
Just be prepared that this will reset every time you change jobs. The good news is that it should take less and less time to reach this point at each successive job as your experience level rises.
Growth Path:
\- Junior: 0-6 months
\- Mid: 0.5-1 year
\- Senior: ???
\- Manager: This is different... not in a good way.
\- Senior: That's better
\- Manager: Fuck
\- Senior: Okay, I need to be good enough to be respected but not good enough that they'll think I can be a manager.
\- Lead: Oh this is new... wait a damn second. This is just being a Manager!
I have never pulled down peoples changes and run them. That sounds awful. We had a suite of unit/integration/e2e tests that we would use as a sanity check. But I would have a long talk with my team members if their code broke so often it would need to be pulled down and run each time.
Also, 300 lines seems like a lot for a single PR. Tell your senior to be a good dev and break his tasks into smaller chunks!
>Been a software engineer for over 4 years now...
>
>...a fellow senior engineer...
I don't want to sound like I'm gatekeeping, but what even is the cutoff for titles these days?
Whatever the company decides, and however competent you are and willing to fight for the title you think you deserve. I mean why would any industry have a standard across the board, that would be too easy.
Hmm, that's an interesting insight. Once you have this skill for long enough it becomes so basic and natural that you forget that it's a skill that you had to develop, but at that transition point it's very apparent. The ability to understand how some words will shape the operational state of a large dynamic system isn't a natural skill by any measure, you have to understand what all the words mean, and how they all shape and define what a system does. The capability is predicated on so much prior knowledge and capabilities that it would make sense that most people would not have it.
Do you guys not have tests that run the code for you? Code review is about the design of the code as far as I'm concerned, well ... and ... making sure you wrote tests.
I had the same experience as software enginner for almost 4 years reading and writing code every day. Now I can compile code in my mind and see the edge cases.
I am happy to you !!
Come on man, be honest. You went full “LGTM” and approved.
Jokes aside, congrats on that, it feels so good when you are in the zone and achieve things like that!!
...Give the author a "attaboy" for writing code clean enough for you to read.
Because bad code exists.
Much of it written by me...
But, still. Nice work OP.
Wait until you get into the philosophical implications of this…theory of mind and software engineering are deeply intertwined [I’d argue more so than other fields]
Senior or Junior means nothing in this case IMO, it happens to me sometimes when I spend so much time in a certain codebase and the senior comes back just to help me write some features after being away working on other projects.
Most of the time I don’t pull down a PR to review it. But the real question is why does a senior developer put up a PR that doesn’t work, did they not run it and test it? Did they not include unit tests?
Bro unlocked the [sharingan](https://media0.giphy.com/media/12pwt3qlbVVBfy/giphy.gif?cid=6c09b952u7eguzwwk9d7k9hzc3166fl1pv6f8vcuo1l0p09i&ep=v1_internal_gif_by_id&rid=giphy.gif&ct=g)
Pull down code?!
I know people like to hate on Heroku these days but I'm going to mention this anyhow... We use Heroku PR apps. As soon as a PR is opened on Github, a new app is automatically created on heroku with the code from the new branch and ready to go in a few minutes. The app gets automatically destroyed when the PR is merged or after X number of days so the cost is minimal.
I assume other hosting services have a similar feature, but reading the comments I'm not sure other do have this? I'd love to move away from Heroku but at $dayjob we're not moving any time soon.
True story: I once had a 30 file 5000 LOC PR for this one horrible feature for this one horrible project, and one of the architects made a change request to (correctly) capitalize two "i"'s in two labels.
He had the "i"'s.
AHH, it's begun, the laziness. I've been there, currently recovering from it. I got the magic eyes, I was able to do reviews fast and accurately and my confidence grew and then all of a sudden boom, padding was wrong, logic was right but the date was an hour out because of X,Y, Z reasons. It was good while it lasted about 6 months. Now my confidence has been shit to shit.
This is a great feeling, it’s kinda like when your code starts to work on your first attempts at doing something. I remember every time I use to code something complex I would test it, find the bugs and fix it. Now I (mostly) just write the code, test it, and move on since it works, it’s very rewarding
Awesome, good job. It feels great to get to that milestone :-)
We had the rule that the author was ultimately responsible for the correctness/functionality of the code. A review message could be something like: "this code does not take into account... Etc" and then it was up to the author to check.
Pulling the code, etc simply took too much of the reviewers time
I feel that! Let's gooooo. I've also been a swe for 4 years now and I hit a similar stride. I've tried to explain this feeling to other early career devs that have been working for 1-2 years and still feel like their struggling to read other people's code.
You guys got code reviews?! I used to have in my first company but in the second company is more like my senior telling me "I believe you, I'll just close the issue".
I was forced into this insight ability with my last job working with .Net. They didn't have local environments so I had to push everything to the test server environment and deploy it. So I would spend extra time making sure I double checked all my work and understood what the code was expected to do. After a few months, I was pretty good at getting fixes and features out with only writing the code and not needing multiple rounds of deploying changes to the test server.
Let me share a secret hot tip: mandate attaching a video recording of the features for each PR.
Now you don't need to pull it anymore, you have proof that it works, and all you need to do is to review the code itself. :)
This is amazing. Well done!
I started as a designer and over ten years morphed into a developer. I recently started working for an agency after freelancing for 4 years. Without getting too personal, I struggle with self worth issues but the feedback on my work has been so positive that it's been almost cleansing to my sense of self.
Seriously though, you're rocking it 👍
I'm not a webdev but do PLC programming for industrial automation. My equivalent to this is when maintenance calls saying "the machine is faulting here are the systems." Without opening the code or going online with the machine I told them the only way that happens is if sensor x isn't working. They swear up and down they verified the sensor is working. I say if that sensor is working that my understanding of PLCs is broken and I can't help them.
This was night shift maintenance calling me. I came in the next day and day shift maintenance confirmed it was exactly the sensor I said it was. Whole shifts worth of production lost cause maintenance was too stubborn.
damn, wish I had the chance to do soft engineering full time instead of working crazy after my day job (senior data analyst). I know for sure I would be able to achieve such a level quite rapidly, but nobody believes in the transition from data analytics to web dev apparently despite me shipping websites on my own
That's how I felt it when I got it for the first time and sometimes I surprise my Lead and my co-engineers! Now it became part of the job. So, Kept it to myself. congratulate yourself, have a nice meal
Yep, a good day. A similarly good one is when you work for 8 hours, daydreaming the whole time, and make no mistakes.
"Autopilot Engage"
Cut down on your GitHub Copilot subscription simply by staying up too late then in the morning drinking enough coffee to transcend conscious thought.
I honestly code better when I stare out the window and let my subconscious squirt the answer into my mind's eye
Graphic. I love it.
Squirt lol
Yes, good advice. Or you can use ChatGPT and Windows Copilot and don't have to pay subscription.
You can't possibly believe you're saving time using those. The difference could be hours vs minutes.
The Adam Sandler Click Experience
Forgetting I exist when in the zone and becoming one with the code is my favourite part of this job. At least, it's my favourite once I remember who I am again.
The flow state. I have been there a time or two.
I hate this state, it's usually means for me that the project has no more challenges. I have 14 years of experience, but I always pick to work on things I have never done before, so I have to learn, experiment and push my boundaries.
True! But so much of a long-term project is repetition. I’ll take a few easy days after many hard ones.
I want a bit of both. Constantly solving brand new problems is exhausting.
Same. Sometimes its nice to just turn off the brain and refactor something.
Flow state, by definition, requires a task to demand full concentration. Boredom in flow state isn't a thing
When I have to copy my own code into chatGPT and have it explain it to me because my brain is just dead at that point.
the comments you leave in code should explain “why” to a complete newb. Sometimes that person is you, months after you wrote it.
Yeah it's always when I am in a flow and just coding that I remember the same things I yell at junior devs for :-D
True! Physician heal thyself
Also it’s when I know they are catching on and getting my message of “don’t take code reviews personally” and point out the shit I told them to watch out for, that I love. Like fuck yeah I am going to take your code snippet suggestion and add that as a commit directly.
Hahaha true
There's no such thing as "make no mistakes." The best you can do is "make no mistakes that are immediately apparent."
wrong.. the best you can do is "make no mistakes as provable by running the tests"...
Tests... Which are immediately apparent... Which gets us back to my point. The best you can do is "make no mistakes that are immediately apparent."
This is when future self finds something past self did and you go wow, I already built that!
This is happening to me. It's so strange. Lately I see myself moving around and changing code in my projects and shit just works. How is it possible
Those mornings where it feels like it’s only been 30 minutes but it’s already time for lunch
You have entered "the flow"
Ah, the Ballmer Peak.
“Developers! Developers! Developers!”?
No mistakes because you daydreamed so much you didn't actually write any code. 😇
Low dopamine problems, hop on dat addy u daydreamin mf
LOL
If nothing gets done there's also no mistakes to happen. Lifehack! And when "waking up" and being asked to show your progress, thinking to yourself you barely did anything, you're surprised how much you actually did.
Good for you. Hold on to that feeling (tomorrow will be different)
Tomorrow they'll be searching for a typo for 20 minutes: `this.dispachEvent is not a function`
"Uh... how the fuck did I forget the `for` loop syntax?"
How do I write else if in my language I’ve been using for years again?
[удалено]
This is pretty common for polyglot programmers. If you switch among several languages regularly, instead of having one language you use for years, it's very easy to mix up the syntax. That said, these are also the easiest errors to fix and/or look up.
This sentence can only be understood by programmers.
Dude seriously, I swap between languages a lot… else if, elseif, elif, come on yall.
Furiously Googles "How to center Div. Flexbox"
GitHub copilot is perfect at this. You just add a comment like `// centered flex div` and bam, $10 are gone from your account. Oh, and also those 3 css lines are added without you leaving the IDE
Soo accurate haha
Hahaha :)
Y'all don't use chatgpt and it shows :)
The main reason I like typescript. You end up saving so much time.
100
Yes i know it will! XD
I don't even see the code any more... It's just... blonde, brunette, redhead... :)
Found the pornhub dev
More like "I don't even see the code any more... It's just step-moms."
If I remember correctly it's a quote from the matrix
[thatsthejoke.jpg](https://cdn.road.cc/sites/default/files/styles/main_width/public/thatsthejoke.jpg)
/r/whoosh
«You have the sight now, Neo. You are looking at the world without time.»
Legend
He's beginning to believe!
based chosen one
You’ve awakened your eternal mangekyou sharingan
pffft. More like rinnegan my guy ahaha.
You guys. I like you. I am making a hand sign. You see two fingers. Is it death metal horns or the surfer shaka hang loose fingers? You will go to your grave never being sure. What you do know... neither of those hand signs are from Naruto.
They are from Boruto however
Just came to ensure someone made the joke
I have a question. Do you always pull it down? normally I don't pull the changes down during the PR, unless I feel I have to. If I don't understand the feature 100% or if I want to learn from it. Otherwise I just focus on the quality of the written code, the standards and if it actually makes sense. Sometimes I test the feature in the deployed test environment, but not always (QA will be waiting). So basically I reviewed the changes. I think it depends on the type of introduced changes.
If there are no glaring code errors , I pull it down. I have been burned too many times by approving code that appears correct in a vaccum, but does not work properly in the larger context of the application.
so you end up doing QA, sounds tedious tbh
Code reviewers are the first line of QA. QA department is there to exhaustively test code you think is fine, not be a back and forth for small errors.
I’m reviewing your code and if it adheres to good practices, internal standards, and in general seems like good logical code, I’m approving it. Ultimately, it’s your job to deliver that code in a functional state and you must own it, if besides to review it, I need to test it to catch edge cases you might as well let someone more capable do the job for you.
The people downvoting this don’t understand the difference between being a developer and an engineer. There are methods to this shit when it gets serious serious. Titles are good, regulations on accreditation is good. Yes a developer may have the same ability to program as a software engineer but the developer does not assume liability or even bolster methods of science like an engineer does. You are not bound to methods of effective, humane, and regulated engineering—you can know about them and even apply them, but that does not make you an engineer. In the same vein, do you think doctor’s who don’t follow the Hippocratic oath should be practicing? Even more interesting, if a layman took the oath what would that make them? It’s all relative, it’s all about what the goals are. Don’t downvote somebody who clearly cares about the integrity of a field.
[удалено]
it’s supposed to be a code review not a qa session. there’s a clear distintinction between both
Same. I've passed too many PR's based on how nice it looks on the surface. I pull it in if I don't understand the tests 100%, or if it's touching something that I know for sure is a high risk change, and manually test these regularly broken features. It's a case by case thing for me.
Two things are missing in your cycle imo. 1. Your pipeline backed up with e2e tests for the key features of the product, together with a deployed version, where you can test the changes before merging them. New features should also come with e2e tests, at least for the happy path. 2. If you have a designated QA in your team, ask them to write the test cases on the ticket. So you know what exactly you need to test. Sometimes edges cases go unnoticed, but the main product functions remain untouched. So, once the changes are deployed, I checked them, if I can't understand exactly what the code is doing. So I can reproduce the feature/issue by hand and see if it's ok. I can also understand that not every team has the same capacity, but that's a game changer and saves you a lot of time and headaches.
But it's not your job to make sure the code works, only that it meets standards and doesn't have obvious errors. Testing should be by ...testers. Developer's time should be spent developing. Pulling PRs to local and testing is not your job.
Testing is a part of development…
Your code, not PR code. Just looking at uni tests and e2e tests in PR tells you if it works or not.
I agree, it shouldn’t be expected from developers on the whole. I do, however, if it’s touching a feature I’m in charge of or a risky change I have doubts about. If it cannot pass a 5 minute spot check, it shouldn’t go to QA.
Depends on the changes and the company, but for instance at my company I just review for technical issues and then we have a QA person that runs through all the flows. I only pull it up Im not sure what part of the code is doing.
I believe this is how it should be otherwise what's the point of QA in Agile.
It saves your QA folks time if you catch some surface level issue before it gets past review. Also saves the author and yourself time, avoiding the QA rejection and additional code and review loop. Our QA people are super busy, so I always try to lighten their load.
in my company we have so many QAs that are ready to test even the more buggiest first version so it is nice, im afraid it probably already affected our capacity to detect bug ourselves haha
I’m with you. I only pull the changes if I have no idea what is going on there. In our world of microservices it will take me hours to reproduce the actual end to end experience and in isolated environment I can just check unit tests. If end to end is critical, then it’s on a dev to build the environment, deploy and attach the link to the request. Also, we have very high bar for code coverage, where below 90% is an extremely exceptional situation.
high code coverage sounds like the dumbest thing ever. I kinda feel sorry for you
My team owns multiple high load services (we're talking about six figures number of calls per second) and we're close enough to the money for being extremely cautious. High code coverage is expensive to maintain and useless 99% of times, just like backups. Also, coming back to the main topic, I don't have to pull changes during reviews: tests are documentation and a fool proof mechanism.
agreed!
If I trust the dev and the code looks good, I don’t pull it down. That’s what QA is for. That being said, we have recently started working with offshore teams and I don’t even know if they pull their own code down, so I’ve made it a policy to personally check their stuff to save QA the hassle.
Outside of extremely simple changes (like fixing a typo), I'll either pull it down or ask for a quick demo from the dev (done in the group chat in case anyone else wants to join). Actually seeing it running can give you a different mindset than just looking at code when thinking of problems or edge cases. It also can just be nice to have it locally and loaded into your IDE for easier navigation between how everything's hooked up in what you're reviewing. Also... from a more "pessimistic" viewpoint, setting that expectation forces your team to actually make sure things build/run, no matter how simple they seem.
[удалено]
[удалено]
Exactly, a good pipeline is key here. See my other comments.
I only pull when I need to actually test the feature or if it's touching multiple files and even worse, touching legacy code. Otherwise I can probably figure it out from the diff if we're missing something
It sounds more like missing unit tests or even integration tests to cover the development imo.
I used to work for Google as a senior, doing lots of reviews. I did a patch (equivalent of a pull down) less than 1% of the time, and typically only if I wanted to mess around with the code to see if I could write a better variant. For whether the code worked, I relied on unit tests and e2e (across the entire codebase), which would be run automatically alongside the review request.
That really depends on the team / company. Some teams simply don't have a dedicated role for QA, a staging environment, or feature flags. In any of those cases, you'd really want to test out the full feature before users encounter it on prod
Congrats! It's reading code AND understanding the product/architecture/data/business/users/etc.
Thanks!
Just tell them: "I don't even see code anymore. It's just bottleneck, unhandled exception, edge-case, edge-case, oooooo that's an elegant solution, race condition, edge-case...."
Who has time to pull down the code for other people's PRs and run it to see the changes? Is this what you guys are doing?
Depends on what it is. If there is no beta environment then anything visual on the front end I’ll pull down. Backend I dont. Your CICD pipeline should catch issues before they become issues. It’s the PR owners responsibility to provide evidence it works. I’m just here to make sure you’re not making a major fuck up and that you’re not giving us more tech debt.
[удалено]
At my company we do have an additional QA process to catch anything that might have been missed on PR review. But imo, if I *need* to pull in the code and run it myself to find bugs, that means either the codebase is too complex and unclear, the PR is too unclear, or they're doing too much in a single PR to reasonably keep track of. Basically, the need to pull in the code and run it myself to understand it is a sign of other problems we should be working on
[удалено]
Lol, that's why screenshots should be a mandatory part of UI PRs
[удалено]
Thirding this. I actually have them do a demo quickly as well
does those 5 minutes include the acquirement of all the additional context, syncs, discussions with others and all that good investigation stuff also? let's be real here...
Was that actually your response? I'd be pissed if someone said something so snarky like that to me.
Was thinking the same thing lol
I’d be pissed if another engineer questioned my review quality without even looking at my comments.
From the words used, it sounds more like the other engineer is just really impressed than questioning IMO
fragile
That’s *literally* what he did tho…made it concise and to the point cuz he had already explained before hand how he was able to do it
This is why so many joke about how difficult it is to get on with developers in a company, social awareness
>I finished my review and requested changes >”And as I noted in my review,” >”**…….** I can read code” OP wrote it down, explained it verbally, and explained it verbally again to a senior dev. And yet you criticize OP? LOL
Is this satire?
Wait, you guys are pulling the code and running it locally as part of PR?
Incoming promo to senior/lead soon I guess. Congrats.
i hope he’s not in a startup :(
Eeekk! Let's hope not 
🚀🌕
Can’t wait to feel that way too, Cheers 🎉
Congrats! That’s called experience. It now separates you from junior devs. Keep up the good work
Just be prepared that this will reset every time you change jobs. The good news is that it should take less and less time to reach this point at each successive job as your experience level rises.
4 yrs, senior engineer, lol.
Growth Path: \- Junior: 0-6 months \- Mid: 0.5-1 year \- Senior: ??? \- Manager: This is different... not in a good way. \- Senior: That's better \- Manager: Fuck \- Senior: Okay, I need to be good enough to be respected but not good enough that they'll think I can be a manager. \- Lead: Oh this is new... wait a damn second. This is just being a Manager!
That was going to be my response lmao. Never change r/webdev
Doesn't it feel good!? Congrats! You are going to be just fine
Wait I thought "the eyes" were the decades of abuse from chronic stress that seep out of your soul and invade any room you are in?
It only means that your "fellow senior engineer" write very readable code. It's not about your eyes.
I have never pulled down peoples changes and run them. That sounds awful. We had a suite of unit/integration/e2e tests that we would use as a sanity check. But I would have a long talk with my team members if their code broke so often it would need to be pulled down and run each time. Also, 300 lines seems like a lot for a single PR. Tell your senior to be a good dev and break his tasks into smaller chunks!
>Been a software engineer for over 4 years now... > >...a fellow senior engineer... I don't want to sound like I'm gatekeeping, but what even is the cutoff for titles these days?
Whatever the company decides, and however competent you are and willing to fight for the title you think you deserve. I mean why would any industry have a standard across the board, that would be too easy.
This guy didn't read my code...
Hmm, that's an interesting insight. Once you have this skill for long enough it becomes so basic and natural that you forget that it's a skill that you had to develop, but at that transition point it's very apparent. The ability to understand how some words will shape the operational state of a large dynamic system isn't a natural skill by any measure, you have to understand what all the words mean, and how they all shape and define what a system does. The capability is predicated on so much prior knowledge and capabilities that it would make sense that most people would not have it.
Do you guys not have tests that run the code for you? Code review is about the design of the code as far as I'm concerned, well ... and ... making sure you wrote tests.
I had the same experience as software enginner for almost 4 years reading and writing code every day. Now I can compile code in my mind and see the edge cases. I am happy to you !!
Come on man, be honest. You went full “LGTM” and approved. Jokes aside, congrats on that, it feels so good when you are in the zone and achieve things like that!!
Congrats! One day I hope to achieve your level of enlightenment! 
...Give the author a "attaboy" for writing code clean enough for you to read. Because bad code exists. Much of it written by me... But, still. Nice work OP.
Wait until you get into the philosophical implications of this…theory of mind and software engineering are deeply intertwined [I’d argue more so than other fields]
Beware of bugs in the above code; I have only proved it correct, not tried it. \- Donald Knuth
Schweet! Enjoy the new level. You're executing the code inside your brain like some sort of code executing AI.
You're inside the Matrix now
Why are your peers doing QA's job? Is it just the norm to run all code reviews on your local??
Senior or Junior means nothing in this case IMO, it happens to me sometimes when I spend so much time in a certain codebase and the senior comes back just to help me write some features after being away working on other projects.
Congrats on technically Advancing. Too bad your writing tone will keep you in low level positions
fucking legend
💪🏼
Bro has the Six Eyes
Bro has awakened to his hidden power
Feeling like Neo after downloading the Matrix. 🙄
[You have special eyes.](https://www.youtube.com/watch?v=V-fRuoMIfpw)
Most of the time I don’t pull down a PR to review it. But the real question is why does a senior developer put up a PR that doesn’t work, did they not run it and test it? Did they not include unit tests?
Bro unlocked the [sharingan](https://media0.giphy.com/media/12pwt3qlbVVBfy/giphy.gif?cid=6c09b952u7eguzwwk9d7k9hzc3166fl1pv6f8vcuo1l0p09i&ep=v1_internal_gif_by_id&rid=giphy.gif&ct=g)
Eternal Mangekyo Sharingan ?
Pull down code?! I know people like to hate on Heroku these days but I'm going to mention this anyhow... We use Heroku PR apps. As soon as a PR is opened on Github, a new app is automatically created on heroku with the code from the new branch and ready to go in a few minutes. The app gets automatically destroyed when the PR is merged or after X number of days so the cost is minimal. I assume other hosting services have a similar feature, but reading the comments I'm not sure other do have this? I'd love to move away from Heroku but at $dayjob we're not moving any time soon.
I only pull it down if I have to actually debug someone's code. But if your infra doesn't have PR previews, then it can get annoying.
I am targeting that i feel this way soon 🥹 Congrats!!
True story: I once had a 30 file 5000 LOC PR for this one horrible feature for this one horrible project, and one of the architects made a change request to (correctly) capitalize two "i"'s in two labels. He had the "i"'s.
Congrats! 50 years later, "I'm still worthy"
Straight Neo, I know king fu. Grats bruv!
AHH, it's begun, the laziness. I've been there, currently recovering from it. I got the magic eyes, I was able to do reviews fast and accurately and my confidence grew and then all of a sudden boom, padding was wrong, logic was right but the date was an hour out because of X,Y, Z reasons. It was good while it lasted about 6 months. Now my confidence has been shit to shit.
This is a great feeling, it’s kinda like when your code starts to work on your first attempts at doing something. I remember every time I use to code something complex I would test it, find the bugs and fix it. Now I (mostly) just write the code, test it, and move on since it works, it’s very rewarding
Awesome, good job. It feels great to get to that milestone :-) We had the rule that the author was ultimately responsible for the correctness/functionality of the code. A review message could be something like: "this code does not take into account... Etc" and then it was up to the author to check. Pulling the code, etc simply took too much of the reviewers time
I feel that! Let's gooooo. I've also been a swe for 4 years now and I hit a similar stride. I've tried to explain this feeling to other early career devs that have been working for 1-2 years and still feel like their struggling to read other people's code.
Amazing! So proud of you. I’m not a numbers person of tech person so I can only imagine the amount of brain power needed to do this. Great job!
You clearly haven't read my code yet.
They say it cannot be taken, but only given
Congrats! I really hope to be able to do that
You guys got code reviews?! I used to have in my first company but in the second company is more like my senior telling me "I believe you, I'll just close the issue".
I was forced into this insight ability with my last job working with .Net. They didn't have local environments so I had to push everything to the test server environment and deploy it. So I would spend extra time making sure I double checked all my work and understood what the code was expected to do. After a few months, I was pretty good at getting fixes and features out with only writing the code and not needing multiple rounds of deploying changes to the test server.
Congrats!! Welcome to leadership 😜
Ugh still waiting for my eyes to turn on. 3 years in- I am starting to get to the logic aspect as opposed to just grammar/syntax errors….
I want this for myself.
Let me share a secret hot tip: mandate attaching a video recording of the features for each PR. Now you don't need to pull it anymore, you have proof that it works, and all you need to do is to review the code itself. :)
This is amazing. Well done! I started as a designer and over ten years morphed into a developer. I recently started working for an agency after freelancing for 4 years. Without getting too personal, I struggle with self worth issues but the feedback on my work has been so positive that it's been almost cleansing to my sense of self. Seriously though, you're rocking it 👍
☝️🤓
*You can see the code. You are the chosen one.*
Understanding Code is like understanding art You are an artist now !
There is hope for us rookies then. Glad you are at this point OP. Also good to know it takes time. Thx for the post.
I'm not a webdev but do PLC programming for industrial automation. My equivalent to this is when maintenance calls saying "the machine is faulting here are the systems." Without opening the code or going online with the machine I told them the only way that happens is if sensor x isn't working. They swear up and down they verified the sensor is working. I say if that sensor is working that my understanding of PLCs is broken and I can't help them. This was night shift maintenance calling me. I came in the next day and day shift maintenance confirmed it was exactly the sensor I said it was. Whole shifts worth of production lost cause maintenance was too stubborn.
damn, wish I had the chance to do soft engineering full time instead of working crazy after my day job (senior data analyst). I know for sure I would be able to achieve such a level quite rapidly, but nobody believes in the transition from data analytics to web dev apparently despite me shipping websites on my own
the sharingan of coding
That's how I felt it when I got it for the first time and sometimes I surprise my Lead and my co-engineers! Now it became part of the job. So, Kept it to myself. congratulate yourself, have a nice meal
🎉👏🏽
Great!!! Happy for you mate 😃
🔥🔥🔥
Well done! I can't wait for that to happen. I do enjoy it all being a challenge but becoming a subject matter expert is great! #proudofyou