Introduction
A few weeks back, I had an epiphany: my code time, and active code time, had a whopping 2 hours difference when working for...
For further actions, you may consider blocking this person and/or reporting abuse
I've never found pair programming to be that great. Too often I'm running through some logic in my head and then the person I am working with, will say "hey what about this", and it throws me off.
And nothing is really stopping them from nitpicking during the pair programming process, they can still say "hey add a new line there".
I do kind of like the idea of just "fixing" nit picks in the review process. If the reviewer sees a typo or a style thing, just append a commit onto the PR and have it merged in.
My latest pair programming were amazing. It depends on how you see and do It.
As a Mid-level I had three jobs, with juniors and with our senior.
With senior level, one was building the backend logics and callbacks on a Kafka consumer environment while another was working on Rails integration and data manipulation sent and received by kafka. We build all together, with little talks between one code and another. Was very prodductive.
With our juniors, I usually allow them do build the whole frontend structure while I build the APIs and backend validations ( Rails, either ). Side by side, without overestimulate or 'build the code' for the juniors, but helping on his doubts. I guess this is, actually, what pair programming is about. And it is freaking amazing for Code Review, Application Testing and validating Bussiness Logics. It all become more approachable and usefull for team.
Pair programming is like programming with a rubber duck. Except the duck talks.
I've done pair programming in short stretches (1-4 weeks), about a dozen times. Those few times were good experiences. The continuous code review in realtime was a huge secondary benefit.
You have a point
Very often it is not possible to fix technical debt because some choice cannot be made yet, or because all developers are overloaded with other work by their manager. I don't think it is fair to always blame it on the developers.
As for code reviews, I find it very valuable to have other colleagues look at my work. Very often they will see things that I missed, or someone will know of a particular way to solve a problem more efficiently.
Code reviews also help block undesirable behavior. There are people who are very fast in writing code and who also have strong opinions, and unguarded can cause trouble. Having a code review step helps to add a bit of resistance and make people re-think what they are about to commit and change.
You can skip code reviews in a team where you can trust everyone (and that allows changes to happen incredibly quickly), but if someone can gain access to a repo and they can just push in changes like anyone else with no guards, you will have trouble.
An example from real life: one guy refactored the entire Redux store of a project from trunk promises to async generators in the purest form of functional programming paradigm. This did made the code shorter, but there were some problems: the guy wasn't a maintainer of that particular project, almost nobody else really wanted to work with such FP style, and there was actually a desire to get rid of that Redux store.
Hmm ideally you want to catch such a cowboy before they make the pull request though. In my opinion code reviews should be a way to collaborate and not a means to catch unwanted behavior. Unwanted behavior should be prevented by using linters, or in the case of your redux cowboy, during work planning...
Yes, you want to build an environment and system that in general encourages healthy behavior. There were multiple levels of missing things that made it possible to have the unwanted behavior.
The other reasons to have code reviews are more valuable. However I still wanted to point out this "hidden" value of code reviews, the value of having the extra bit of friction and it's indirect causes on human behavior.
Could add poor tooling to the list. I work at a company that doesn't even have source control, on top of most things you mentioned.
I once asked my non-technical manager how I would recover lost files that were not yet in production. His suggestion was to be more careful about what I deleted...
I moved on fairly quickly after that.
That's a also a valid issue.
I feel like tools can help to address these issues but also important is the culture change needed to even recognize there's a problem worth fixing. I feel that's often the biggest challenge.
How would you go about making a case for better documentation for example? Say to someone who believes gut feeling and asking so and so for help is a better approach?
Bei einem meiner Jobs war tatsächlich das mental anstrengendste: Nicht bei den Meetings (Monologen) einzuschlafen. Fast so anstrengend, wie sich dann durch einen Fremdcode zu wühlen, der nach den dort festgelegten Konventionen erstellt wurde und in dem jeder Variablenname aus einem Roman bestand.
Thanks for sharing
This is a great list! Can I add just one thing?
Thanks a lot!
Great post! There are so many day-to-day activities that might be necessary and helpful, but by not managing them correctly they can really affect our productivity and overall performance
Absolutely! It's remarkable how the little things that we might even ignore or not considered them as unproducitve can hinder our productivity.
How do you overcome a lack of productivity?
It starts by saying 'no' but explain why you say no. For instance a meeting that you're invited to but you know you will only be a listener. You can probably decline. With introducing technical debt you should say no when you know it will cost al lot of effort to fix later. If they insist ask for an email confirming that they want to introduce the technical debt so that you are covered and decisions have a paper trail. These two will already help a lot to gain productivity. (25+ years of dev experience)
Good idea to avoid those situations. Everybody should learn to say "No".
Good to know information's, Thank you.
I need to add missing leadership and resulting unclear requirements.