221–230 of 301 posts
Earlier quoted context omitted.
So in all three cases, your focus is gone and what you were doing has stopped.
Helping a junior and maintaining relationships with your fellow seniors is a part of the job too.
> in my team culture it’s not frowned upon to “snoop behind” people writing code. Whenever I sensed something interesting going on, I’d roll around and watch what was happening. Agh, I'd hate that. In fact if anything interesting had been going on on my screen it would immediately stop, no way I could work with someone watching. I struggle enough at desks with my back to a door or where people walk by, just can't sto…
I've read that in feng shui what you describe is called the "command position". I'm not able to work with my back to a crowd. That's a recipe for anxiety. I quit a company when they moved my desk so my back was to a hallway, and refused to compromise on this issue in any way.
I have had private offices, two person offices, cubicles, and once in a bull pen with a glass wall. (we called it 'the fish bowl').
Private office comes in first! Cubicle (as long as the walls are at least five feet) comes in a close second.
Open floor plan (or a bull pen) comes in far far far last.
All source code eventually "wears out" and has to be rewritten.
Earlier quoted context omitted.
For me, it depends on who is creeping. A junior engineer, I'd probably pull them up and start explaining what is going on. A fellow senior engineer I'd probably take a welcome break and ask them to grab a coffee - the only reason they'd be lurking lol. If it is a PM or someone else it might put me on edge - likely because they wouldn't have the context to understand what I was working on and if they didn't say anythi…
So in all three cases, your focus is gone and what you were doing has stopped.
Earlier quoted context omitted.
I don't. I could never really pair programming, even in school. Interestingly, I can share my screen with people that have different tasks than mine. I just can't make it work when both people have the same state of mind.
pair programming is really a forced socializing in a field where a lot of people have trouble socializing, never really understood how it got as far as it did.
Earlier quoted context omitted.
Error message phrasing is really very important, but it’s probably better to have that refined in code review or to have some explicit step for it.
Error message phrasing should not be in code. It should be in localization files, even for the default language, and not require a developer to modify.
Earlier quoted context omitted.
the more testing the better? while having tests at unit and integration levels are good... Test as little as possible/responsible. I think it was Kent Beck who first articulated that, though it was something many people converged on in the early 2000s in the XP world. Of course it doesn't mean test nothing, it's recognizing tests are liabilities (as all code is) and we need to make sure they are serving a purpose oth…
Wasn't it Kent Beck who came up with Extreme Programming and Test-Driven Development? I think testing was one of the big corner-stones of XP. At what point did that turn into "Test as little as possible"? "Unit tests are one of the CORNER STONES of Extreme Programming (XP)" http://www.extremeprogramming.org/rules/unittests.html Also see: https://hygger.io/blog/tests-in-extreme-programming/ If development is tests-dri…
this is his SO answer where he talks about it... https://stackoverflow.com/questions/153234/how-deep-are-your...
Earlier quoted context omitted.
If it happens again, I've been told that having a mirror on your desk so that you can see what's going on behind you can help a lot.
You likely already have one. The upper bezel of your monitor is likely shiny black. It makes a great mirror to know when someone behind you is taking interest in you. It is also completely inconspicuous and you do not need to move your head from your monitor to use it.
Just to toss in my two cents about testing: Unit tests are for refactoring and declaring behaviour. Additionally, a lot of people have made the same observation: Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function, think about how you can change your design to make testing easier. It will probably improve your code quality. Integration tests a…
I would say that unit tests impede refactoring. If your refactoring changes classes interfaces or API, you are likely to have to change your unit tests as well.
> Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function
Same goes with documentation. If you can't explain simply what a function does, you may want to rewrite it.