People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying. Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of times faster than screwing around by yourself. Pointed-haired bosses and accountants will never understand this. If you pair and rotate, the inexperienced person becomes experienced quickly, and it's viral if you also do rotating pairing. A team with one expert and pairing is now a team full of experts.
If you worked at a place that did 100% pair programming, anyone who couldn’t succeed at pair programming would be filtered out.
Personally, whether or not I can do pair programming has a lot to do who I’m working with, what I’m doing, and what kind of day I’m having. The same thing goes for test-driven development. I have ADHD and short-term memory issues.
This causes me to work by feel on some tasks because I don’t work on problems in order. I visualize everything like a house of cards. I see everything at once and load random parts of what I’m looking at until I see the whole thing in my minds eye. (Because I have three logical registers on a good day.)
Asking me to explain my thinking requires me to restructure the process in reverse and put it into a linear thought that can be understood by someone else. Which half the time dumps all of the registers in my short term memory. Meaning I don’t understand what I was looking at. Communicating with neuro-typical people is frustrating, mostly because I try really hard to communicate clearly. (Good communication means better relationships with coworkers and less wasted code.)
Despite the complete chaos in my brain, I write extremely good code (by other people’s measures), because I think about readability, algorithmic complexity, side effects, testability, and a thousand other minor details at the same time. Tests come in once I’m happy with the structure. (I hate working without clean understandable tests!) Then I refactor to clean up the code and comment to explain reasons why it was written specific ways, so coworkers (or future Kayodé) don’t want to murder me.
If this comment is a bit rambling, you know why. :)
Thanks for posting this. Yesterday I came across a job position on a company that does 100% mob(!) programming everyday¹. This means every programmer works 6 hours per day on a zoom call with 2 other programmers, rotating roles between typist, navigator and support every ten minutes.
I couldn't help but feel my soul being slowly crushed as I read further on their description of the daily activities. Needless to say, the filter indeed worked out. As someone with ADHD, I couldn't last a single day on a job like that.
I've been in a team that does this. I did appreciate the knowledge share from the expert the first month despite the fact it completely drained me. After awhile, I hated the whole thing and dreaded going to work. I get it works for some people, but I know it is not for me.
> on a zoom call
This would make this about 10 times worse. I wouldn't last a week.
what better way to ensure you get CS degreed ppl for positions that legally can't require one than to reproduce the "group project" model as an organizational principle?
CS group projects are biting like pair programming. Most CS group projects I've been on were a game of chicken where everyone would wait for others to do the work. If you don't pull your weight on pair programming it's quickly obvious and you'll get feedback.
At this point I suspect that the "group projects" often done in CS degrees are actually intended to give the student experience in a failed project and learning from their mistakes, and understanding that not every project is a success or failure due to their actions alone.
Kind of backfired for me, because only very rarely were professors able to assign projects that were big enough that I couldn't do them entirely by myself, and I was outright incentivized to do so because even working at that speed I could still produce the whole project at A-grade quality when my teammates would have been satisfied with a B or a C.
Another cynical take would be that you were given perfect training for a software team in industry. Every team tends to have a small number of individuals trying to get that A, while their colleagues are not only satisfied with a B or a C but spend most of their days in meetings trying to ensure they drag down the software to their target.
I can only speak for the U.S., but "required to actually do the work" has nothing to do with whether or not I'm legally allowed to set a requirement for a job.
There are protected classes/categories that can't be part of the employment decision, but outside of those, the employer is free to set whatever criteria they want for the position.
If I run a plumbing company, I could say "all of our plumbers must have a computer science degree," and I can't imagine there's any legal reason I couldn't do that. I'd certainly have a recruiting problem, but not a legal problem as far as I'm aware.
If the requirement has a disparate impact on one of those protected classes, you can run into problems in the US.
So in the case of plumbers, if a plaintiff can show that you are hiring fewer women because women are less likely to have CS degree—then you would need to show a “demonstrable relationship to the requirements of the job” for a CS degree.
However, this isn’t an issue for software developer positions. A CS degree doesn’t have to be absolutely necessary to be able to perform the job, it just needs a demonstrable relationship to the job requirement. There is also already precedent that a degree in a related field does meet that requirement.
In fact, depending on regulations, it can happen that you end up with somewhat junior team member having to sign off on all materials because they are the only one with necessary accredited title...
There’s no problem with requiring a CS degree for every single software developer, software engineer, programmer, or coder job. Since those are the kinds of jobs that were obviously being discussed it’s not “almost all”, it’s essentially none.
The worst group project I did in course of my studies didn't have the same level of forced interaction as pair/mob programming. In fact, I'd say it tended to have less than normal work from the office.
Very bluntly put: full-time pair and/or mob programming is for and by neurotypical extroverts. People for who their job is a social activity, for who deep work and deep focus on their own are mostly foreign concepts.
I mean to each their own, but companies - and fellow developers - need to stop forcing others into their way of working. Having One True Way of doing things is always bad. But yes, this may mean there will be a divide in your company / teams, where one part prefers solo work while others prefer group work. Deal with it. Compromise. Let the extroverts work on their own for a while, and the introverts do some pair programming, but don't go all in on one or the other.
I'm not sure why a company needs to work in a certain way just because some people don't like to work in that way. It is like saying a java shop needs to use c# as well just because some people are more comfortable with c#. No. They don't. It is just fine for developers that want to write in c# to find a company that is invested in a culture around doing c#.
This isn't just true with programming. If you like to do things solo, then don't become an airline pilot since they always work in pairs. There are plenty of other places you can work as a solo pilot. Airline pilots work in pairs because, for that type of work, there are advantages to doing so. If a company wants to "go all in" on pair or mob programming, there may be very good reasons for doing so and trying to have a split culture doesn't always work.
I resonate with your comment and the comment before. Every time I've had to pair program it has completely drained me. It's impossible to both do the deep logistic work component in my head and communicate clearly with someone else. It's like too many tasks working at the same time. I've never tried to itemize how my brain works in that regards though.
Thanks for both of your comments. The mob programming sounds like I would be depleted way to fast.
Doing this in person sounds bad, doing this over Zoom would be monstrous. Back at a previous job I had to do pairing for many hours of the day over Zoom with less experienced developers, and it was unpleasant to say the least!
I went to that interview a few years ago. I got to experience the mob live programming interview. It sounded bad going in but things often turn out better. It felt like I was live streaming on twitch with a small disinterested following. Hard to imagine 6 hours a day in that state. It feels like one of those places that will make you rethink if you want to remain in the industry.
Honestly, it's sounds kinda insane. Mob programming certainly is a tool with its good use cases, like maybe tracking a bug, onboarding a new team member or making critical changes to core stuff.
However, I just can't imagine having three engineers making 100k+ sitted together everyday on a single laptop to write yet another REST api or whatever.
Compare that to 3 engineers struggling through solving problems in isolation because they lack information that is in each other's head.
Culturally traditional management is biased to create the 3 struggling engineers scenario because most management strongly believes that people working on many tasks in parallel is peak efficiency. You see this manifest in places that run the Jira + PR feature mill. Staff that complete lots of jiras and have lots of green dots PRs in their GitHub profile are considered "peak performers"
The fortune 500 is littered with companies full of this anti-pattern. Less so each year though, because if amazing execution on digital transformation matters to the business, to the extent those 3 struggling engineers execute poorly, the competition slowly eats the incumbent's market share.
There's a big difference between "free flow of information" between engineers and enforced mob programming. The former often works quite well with just regular unstructured meetings, whether face to face or online.
We use "mob programming" once a week for 30 minutes, in a way that you described - a "Sentry Smackdown". In zoom, we find 3 of the most "interesting" sentry errors, split up into 3 break out rooms, each group sees what they can find, then 5 minutes at the end to give our update and next steps.
I love it and it's helped get momentum on things which would typically just sit there. BUT, 30 minutes is definitely my maximum for something like this.... even if we did something minor like make this meeting 1 hour long - I would dread it.
Context: we do have an engineer on-call (on a weekly basis) and they will respond to urgent sentry errors, but the above helps sentry errors with less urgency get moving without being a total buzkill for the on-call engineer to look at ALL of them.
I love pair programming !!!for specific tasks!!! Just like TDD, i think its pragmatic and should be based on your needs. But all or nothing, naaa, thats just coolaid or micromanagement.
Wow. I recommend everyone read through that page. Some may love it. Obviously the bosses at SOCi do. For me it is a dystopian nightmare.
To summarize: there are three roles, Typist, Navigator, and Support.
The Typist is not allowed to think. They are explicitly described as a "smart input device". For the most part, only the Navigator is allowed to think. They tell the Typist exactly what to type, and the Typist must follow everything the Navigator speaks, to the letter.
The Support only looks over both their shoulders and sets a 10 minute timer after which the roles rotate. Yes, every 10 minutes everyone switches roles.
When working in person, one thing this selects for is people with perfect vision. Elderly programmers need not apply!
Why do I say that? Well, I have computer glasses that let me see my screen perfectly even at my age. This applies to anyone over 40-50: if you don't have them already, I strongly recommend getting a pair of single vision prescription lenses tuned for your normal distance from the screen. Since I use a laptop, these glasses are set for a 20" focus distance. I have two external monitors (one landscape above the laptop, the other in portrait mode to one side), and I keep those at the same 20" distance from my eyes. It is glorious! Everything is in focus, all the time.
If we're sitting around a desk, it's almost certain that I won't be able to read what's on your screen, for the simple reason that it won't be at a distance that brings it into focus (probably much too far away).
Oh, and you may like dark themes and tiny fonts like all the young people use these days. So even if it were at the right distance I wouldn't be able to read what's on the screen.
Mobbing on a Zoom call mitigates the focus distance, but the dark theme and tiny fonts would still mean I can't see your code.
And webcams are supposed to be on all the time so your fellow mobsters can see your face. A nice sentiment, but two problems:
1. I can't work sitting. If I do, I fall asleep after a while.
2. I can work standing, but not standing still! (I'm no John Carmack, who can give an hour long talk without moving a muscle.) I have to move around in order to think and stay alive. So I would constantly be walking in and out of camera range, or stretching, or wiggling around on my Fluidstance balance board, or just looking out the window for a vision break.
A more delicate problem: Sometimes older people need to take more frequent bathroom breaks, and the timing may be unpredictable, especially for someone like me who eats a lot of fiber for intestinal health. Sorry, I may not be able to just "hold it" until the next scheduled mob break. (Apologies for the TMI.)
This whole thing is an ADA compliance lawsuit just waiting to happen. (And no, I'm not going to be the test case; I have no interest in working for a company with these practices.)
Thank you for your insights! While the idea is interesting, the images on top of the SOCi article support your sceptism: Three programmers gathered around a tiny laptop screen is awful. You can always increase the font size though - I regularly work with a fairly large font as it is not as straining for long periods, but how do you persuade your coworkers to that? It takes quite some getting used to the diminished screen space.
That said, I would never want to join a company that has phrases like
> The mob disbands, either to sleep, or to their individual work
and
> [...] full 8 hours of programming [...] minimum expectations [...] additional time is expected to be put in
That is literly a description of programming hell for me (20+yrs also here). My fingers are so much better at streaming my thoughts them my mouth which often struggles to keep up.
Yep, same here. And people are also not very good at listening; even if you are focusing only to type, people miss stuff and I have to repeat or explain in another way while I could have typed things 100x myself in that time. I think I’ll give this weirdness a miss.
Christ almighty, that sounds more similar to one of those inane "team building" exercises that they make you do on corporate retreats rather than actual work.
> When working in person, one thing this selects for is people with perfect vision. Elderly programmers need not apply! ... prescription for 20" focus ...
I went the other way. 42in 4K TV placed further back. Big font. Zero eyestrain.
The main trick is that you have to set up the TV in "Game Mode" to turn off input processing, and also turn off stuff like overscan.
Obviously this setup may not work in a office cubicle or other space-constrained space.
Works fine for in-person reviews in the time of Covid, the other person isn't hovering over my shoulder either. They can stay way back and still see what's going on.
Provigil solves the sleep issue. But I’m a bit younger and I also cannot read dark themes. It’s especially infuriating that half the default font colors appear to be dark shades as well, so it’s dark on dark.
Drug your employees so they appear to be working the desired hours. I can see ethical problems with that idea. The employer should at least be dispensing the drugs for free as a "benefit".
Seems a bit draconian to force mob programming onto every programmer everyday, but I also find the idea appealing if I was selecting the team & when to do it -- there are definitely teams & topics where I would find this flow productive & helpful! For example, we had a similar arrangement back when we were doing ACM programming competitions.
In similar conditions, like Capture the Flag competitions, we regularly used short-term arrangements that might seem like mob programming, often by just deciding to go to whiteboard and try to figure out the problem and thus implicitly inviting others to join if they have spare cycles.
Wildly different experience compared to mob/pair programming all the time.
tangential question: I'm 37 and think I have ADHD. My partner thinks I do, and when I read posts like this I deeply identify with them. What should I do? Get a diagnosis? My ignorance thinks the only course after that is drugs which doesn't sound that appealing..
I got diagnosed at 35. Definitely do it -- it's been life changing for me.
But don't stop with a diagnosis, get some coaching from an ADHD specialist. There's so much more to it than just attention -- emotional dysregulation, time-blindess, executive function impairment.
It's a whole thing. But with support you can cope with most of it. And most importantly learn to separate the condition from.your character.
You have lots of options. Meds always sound unappealing but they can be a huge boon for some. CBT can be very useful pretty quickly without any sort of drug, but it’s not for everyone. Executive Functioning coaches (not “executive coaches!”) can be useful for practical work/life organization strategies. Date around with EF coaches because many people with vastly different qualification levels work under that name.
Diagnosis can be emotionally helpful— they’re often done by neuropsych evaluation specialists but you should talk to a psychologist or psychiatrist first because evaluation is a few grand, most insurances won’t cover it if you don’t seem very likely to be diagnosed including DSM-V criteria like having significant life changing symptoms before age 12. The testing itself is a few hours of tests designed to push you to your limits for things like working memory, impulsivity, and reaction time. (I was waiting for the tester to say “Reaction time is a factor in this, so please pay attention.”) Parts got frustrating but not like Megaman frustrating.
Depression and/or anxiety are commodities in 80% of those afflicted, so that’s worth paying attention to also.
Getting a diagnosis does not mean having to medicate. If it’s not for you, you can get non-medical forms of help. Not help as in you need help but rather help to make your life easier.
If you think you may have ADHD, definitely worth it to understand more about ADHD and a diagnosis will help those close to you to understand your behavior.
I highly recommend talking to a psychiatrist or psychologist that can see if you fit the criteria. However, if you’re willing to do your own research, you may be able to find a family doctor willing to let you try a few mediations before referring you to a specialist. (I did.)
ADHD medication is excellent from a patient’s perspective. The first-line ones are almost immediately effective. If you don’t like what they do, you can just stop taking them and try another one. In less than a year, you can try most of the known-working medications.
Even if nothing comes of it, at least you know. Knowing is half the battle. :)
I’d suggest trying the meds before you form an option on them. I take my ADHD meds every day just the same as somebody else takes heart medicine or wears glasses. It just is what it is.
And note: it does sometimes make you feel like cheating or something… you will have to arrive at your own conclusions. Suggest a good therapist to help deal with it.
This is the one; one diagnosis for ADHD is to take the medication and see how you feel. I've heard a colleague, also in his 30's, describe it as his head finally going quiet. I've tried my girlfriend's medication (also a mid-30's diagnosis) and it didn't have that effect, I just noticed I was a lot more deliberate in focusing on and switching between tasks.
Why would you report yourself as a health & safety risk? You're all good :)
Your partner is worried. So shift the work/life balance to have more life with your partner. Trust the team at work to understand.
Diagnosis from other people does lead to prescription drugs being offered. If someone reading is using chemicals, please pay close attention. Some doctors attempt to prescribe drugs in increasing quantities. That is not the path to sustainable balance. Medications are useful in an ambulance or hospital, they do help in emergencies! But they're not intended to be used routinely for a healthy life.
Peer support is best. Finding humble, open-minded peers can be challenging. The CouchSurfing (now BeWelcome) community is very open-minded and humble. Many church friends are humble. Teaching from the Bible is a reminder of how none of us are perfect, yet God forgives, and shows grace, mercy, and peace.
Some companies try to force concepts like pair programming, mob programming, etc upon their "human resources". It works well for people who like talking & body language, but not for people who prefer reading, typing & listening to music. Personally I prefer reading & typing, and that's why I use Hacker News.
You're not alone, you're welcome here. Interruptions are OK despite the cost of context switching. Diagnosis is not needed, you've already found help. I pray that God will bless you with peace in your personal and professional life, and they'll all catch up to your high-frequency genius ideas soon :)
Pair programming for integrations or maintenance might be ok, but for new projects that is like having multiple people write a novel. Not only will it be pulled in many directions, it may eliminate some great innovations. Usually one person in the pair also has more influence politically in the company so they get their way.
There is a reason why nearly all good programming languages, standards, platforms and even games are usually started and prototyped by one developer. That is because programming is creative value creation and business/finance/project managers passionately want it to not be, they want it to be a factory and it never was, is or will be that until the initial versions are out. They want to value extract before the value creation, they also try their hardest to make sure no programmer has much power so they are "swappable" which again is not true in product creation, maybe maintenance or once the base is created, but not initially.
Programming is a creative skill and should always be seen that way. Most product developers, game developers and full stack to presentation developers know this and can make some of the best value creation because they can take it from start to finish. Once it is prototyped or first versions, it can be ramped up for value extraction.
This is so true, and it's why I passionately hate pair programming. Also: Scrum, which is another one of these attempts at turning software engineering into assembly line work. Partially successful in case of maintenance-heavy projects, but a disaster every time I witnessed it being applied to early-stage foundation building.
When prototyping some new idea that might result in a new product/platform/module/whatever, I tend to iterate faster than I could explain my iterations to any other person, even well-versed developers, let alone average-skilled ones. It is normal to refactor the entire codebase multiple times a day in such situations. The internal reasoning processes that guide these iterations, the probability assessments followed by quick trials followed by another iteration that ultimately lead to a solution are so manifold and dealing with so many particulate details (that are of utmost importance however at such an early stage of a new system) that it is impossible and impractical to discuss all of them with someone. You just have to follow your intuition. Having two intuitions in play at this stage is counterproductive, the friction losses are just way too big.
> Pair programming for integrations or maintenance might be ok, but for new projects that is like having multiple people write a novel. Not only will it be pulled in many directions, it may eliminate some great innovations. Usually one person in the pair also has more influence politically in the company so they get their way.
This feels pretty relatable and sometimes also extends to code review, when another developer essentially goes: "Hmm, i don't like this for subjective reasons, you should rewrite it to be different." even in situations where doing so would have no tangible benefits and the only thing that ends up happening is the development velocity being ruined.
I think that sort of problem would manifest itself both in pair/mob programming, architecture discussions, sprint planning as well as code review, it's not like you can easily avoid it altogether, unless you avoid the people in question entirely or provide pushback against nitpicking and bikeshedding, which may or may not be viable.
> That's why code review process must have a guidebook with a rule "it's on the reviewer to show why the suggested change has a tangible benefit".
Agreed, yet you're implying that:
- there must be a guidebook in the first place
- that it must actively be followed
Sadly, that is not the case in many environments, where disagreeing with another developer might actually make you waste more time discussing (or rather) arguing things back and forth, rather than just doing the changes that they want.
It's unfortunate people are mostly conditioned to not oppose: whether to get branches landed faster, or simply because of the imposter syndrome, but some of us who are good at opposing and saying no sometimes struggle to find the right balance.
My goal when reviewing is to help others learn something new, which is why I'll sometimes share a personal, subjective preference for an approach (with "subjective" meaning that there are pros and cons to either approach with neither being better in every circumstance, especially in a legacy codebase like they all are).
I am trying to walk the fine line between teaching someone something potentially new, and not dumping on their velocity or self-confidence. I love it when people acknowledge the idea and say "nope", yet I understand that many won't do that, so most of the time, I stop myself from even sharing my subjective preference.
Outside of character, it requires building trust between people and not being out there to "prove your mettle", but to build stuff together. And with so much churn in jobs and remote work (I haven't met my new coworkers of 6 months yet, and I haven't met half the previous team either), that's sometimes hard.
I don't think one requires ADHD and/or short-term memory issues to struggle with serializing their internal state verbally without disrupting said internal state when it's sufficiently broad and deep in complexity.
This is literally the problem with interruptions and open-office floor plans for knowledge workers. There's no effing way we're all ADHD-addled goldfish. Decades ago my senior cube-mate liked to tell non-engineers who walked into our cube asking questions unannounced: "like I tell my wife, we're in here balancing a stack of plates in our heads, and you just walked in here and knocked them all down."
You're right about it being a house of cards, and the industry isn't doing us any favors selecting for people who can chat about it vs. arrange the metaphorical cards high and get the hard things done.
combining serializing their internal state verbally without disrupting said internal state when it's sufficiently broad and deep in complexity.
I struggle with this during technical interviews. I can't think deeply and explain what I'm doing at the same time. Since talking is required it means that I can't think.
Yeah, I try not to interrupt candidates unless they clearly misunderstood the problem and are building something that doesn’t show their expertise but they think I want. I voted hire on a guy who worked silently for over half an hour and ended up with a good solution, though it’s a little more persuasive for a candidate to offer more signals in case the final code doesn’t come out right.
As someone also with ADHD, I can relate in a lot of these respects. The idea of doing pair programming every fucking day would ruin me. I really don't mind collaborating or discussing with people, because I think that's what our brains are great for, but not in the pair programming sense, and not every day. In my last job, I was very open about this, but my manager seemed to basically brush it off and pull up a chair whenever he felt that was cool. "Time for pair programming". Bleh, thankfully I burnt out and got fired.
I've been following a very similar path as you describe in your last paragraph, and I'd be very curious if there are other similarities that differ from how others write code.
By chance, do you struggle with eating sounds in offices to the point where you panic?
I don't think I have ADHD, but I burned out pretty quickly after a few months of 8h/day pair programming. I started taking medication and took some extended vacation.
Thankfully the CEO of the company wasn't much into it, so he forced our pointy-haired boss of a manager to make it optional.
The whole team unanimously decided to never do it again.
This almost made me tear up. I've genuinely never thought before this thread that there were companies that did this, and that it's just not a big deal to people with decision making power. I don't do anything for 8 hrs a day, but if I had no choice but to be doing 8 hrs per day of pair programming, I'd really be having some dark thoughts. Not exaggerating, this scares the shit out of me. Thanks for sharing. I actually feel like I need to step away from my computer and relax a bit just trying to imagine myself in that position.
Yeah, in this case was a single manager abusing his power, who doubled down whenever we aired our grievances, to the point of forbidding talking about it. The CEO however was more sympathetic to our pleas.
The 8h shift looking at a shared screen was absolute terror. No privacy, a lot of machismo with people claiming "I don't need to look at the documentation", terrible productivity when pairing with certain employees that didn't really took the work seriously.
Mandatory pairing simply doesn't work, period. It's like they say about therapy, wanting to do it is a pre-requisite for it working...
Makes me almost wonder what management is actually good for, besides a high level filtering system...
I like continous pair programming, but not because I actually continuously pair - if someone wants to watch me work, or is too green to go it alone quite yet, its fine. But usually we only pair when it makes sense to, i.e. we are at the beginning of something and figuring out what to split up.
If management tried to force real continuous pairing down everyone's throat all the time....yeah no. That management should be fired, they don't understand how people work.
Ya, seems reasonable enough. You have control over the gate, either to teach or to work something out. People are allowed to have an opinion on this in general.
I had a coworker at the same last job I mentioned, that sat next to me in our open office, and used to crack and eat eggs at his desk, among 4 other meals that he'd decide not to bring to the kitchen. I literally couldn't find a pair of earmuffs or headphones that could help me get back in the zone after hearing that.
> By chance, do you struggle with eating sounds in offices to the point where you panic?
Not particularly, but having to deal with distacting sounds, pressure to focus, and feeling trapped in a cubical can definitely make me uncomfortably anxious.
> By chance, do you struggle with eating sounds in offices to the point where you panic?
Not to be rude, but the stereotype of the software developer is fast becoming one of fragility. A low wage worker spending their day working a fryer or a guy at a construction site would be thrilled to have such working conditions to where their biggest problem is someone eating too closely while making $100k+ per year in the air conditioning.
I’m going to assume good intent and resist posting a snarky response.
Why is it so terrible for anyone to want to work in a specific environment that they find comfortable? Why do you think that the ability to work as a fryer or construction worker is somehow “better”? Why are people who have the capacity to either ignore or tolerate bad working conditions and continue working considered morally superior?
As human beings we’re all so different and unique in our ways and preferences. We are at a stage in our evolution where we can provide people the kind of environment that they prefer to work in; even let people choose the kind of body and gender they think works best for them. Why is that so bad? Can’t we just let go of the toxic masculinity involved in such comparisons?
I am not even touching on the nature of knowledge work itself which has very little to do with physical toughness and everything with being in environments conducive to problem solving. Please just stop with these rubbish admonishments.
interesting that you equate “fragility” with the opposite of “morally superior” - “Fragile” seems like a fairly accurate description of the described phenomenon, you are the one who seems to be ascribing moral value on the basis of that description. Why is that? Why should we care if someone else describes us as “fragile”?
Only if the person in question is merely annoyed by such sounds.
For some people, it’s quite literally perceived as someone’s kid screaming next to them.
What people forget is, we don’t have a choice. People who have a disability will have to deal with it no matter what job they do.
It’s like yelling at a person in a wheelchair to stop bitching about the lack of an elevator in a three-story office building because they have a “good job” and getting up the stairs isn’t a big deal because you do it every day.
This analogy may sound like an exaggeration, because there is no way you can comprehend something so minor and trivial could be a problem. And that’s kind of the point. It’s extremely difficult to understand something you haven’t experienced.
Most people jump to the conclusion that these things aren’t a big deal and they’ve seen people lie about it to manipulate people. Therefore, a person claiming to have a disability that isn’t obvious is lying to get things they don’t deserve.
Not everyone has a fully working brain or body. :(
I find it far easier to program in an automotive shop (banging, yelling, loud revving, etc) than in an open office next to someone slurping food every twenty seconds. Well, that's unfair, as in the former I had almost no problems getting into flow. I expect it's similar for people who like working in coffee shops.
Software work is fragile, just like all kind of deep work, because you're holding everything in your head. I've worked in fast food and in software. In fast food I was constantly thinking about lots of things all the time, because it's mostly physical work. I can't do that in software, I need my mind to be here to work. That also means that in fast food interruptions weren't a big deal. Everything you work with is physical, it's right here, it won't disappear. Thoughts are not like that, they are fragile, you have to protect them.
Of course I'm happy to work in software rather than in fast food. And I think many people would prefer working a desk job rather than a physical job. But humans get used to things. I remember my time working in fast food, but it's hard to remember exactly how I felt and say "Wow, working in an office is way better" every time I encounter something that I don't like in an office. I also think that just because I have better working conditions now doesn't mean I should stop trying to improve them.
>Not to be rude, but the stereotype of the software developer is fast becoming one of fragility. A low wage worker spending their day working a fryer or a guy at a construction site would be thrilled to have such working conditions to where their biggest problem is someone eating too closely while making $100k+ per year in the air conditioning.
Oh my! People complaining about things that are relative to the situation they are in! How fragile!
The only thing I find rude about this is that I don't see how it's relevant, and maybe that it implies it's an optional emotional response, or a recent one. I get where you're coming from, but it has nothing to do with software developers, and also who cares about their identity as a tough software developer more than their own sanity!?
I've worked blue collar jobs. I've sold cars. I was in the infantry. I still hate listening to someone eat in close proximity, smelling their food and farts and all the other things people do in the office.
I keep putting off getting a formal ADHD diagnosis, but this sounds a lot like me. :) My programming/thinking style is very instinctual and doesn't really fit any sort of linear style. I kind of put things together as I go, trusting my subconscious to get all the little details together. I can explain post hoc why I wrote something a certain way, but won't be able to do it beforehand.
I'm the same way and my commits reflect that. I've never stood how people could organize their commits in linear progression. I always squash my commits before merging because of this.
I too have an attention deficit and bad memory (this is why I hate interviews where you are asked to recite concepts and textbooks definitions, framework functions with parameters and so on). I get over it by understanding the concepts, understanding the big picture and researching today what I just forgot two months ago.
I think you are mistaking in believing you have trouble explaining because you use a different thought process.
For almost everyone of us, figuring a complex system means you deconstruct the system in small pieces, understand the small pieces, construct the system again in your mind along with making a kind of mind diagram about how it works. But when it comes to explain to others you use a different process than you used to figure it out. You already have that mind diagram, so you proceed like in most text books or in articles by already providing the big picture and going in details only when you feel is needed.
I also write good code, but it doesn't have anything to do with attention or memory. You write good code because you believe it's important to have something that is working well and also will be readable and maintainable. And writing good code is something almost every programmer can do if the working environments permits - i.e. they are not valuing churning bad code fast over writing good, reliable code.
Aside from one's subjective take on pair programming -- and there are obviously many valid reasons why it doesn't work for some folks -- I'd have to guess that doing it 100% of the time is quite inefficient. Software development presents a wide variety of tasks of varying cognitive difficulty. I tend to believe that pair programming's sweet spot is for tasks of medium to medium-high levels of difficulty.
For the most challenging tasks, say, coming up with an original solution to an unsolved problem, I think it's better to alternate deep focused thinking alone with group brainstorming. But you really need that meditative alone time to gnaw at difficult problems -- for me it tends to be in the shower, or during a walk. That's where you have those awesome "Aha!" moments.
On the other end of the scale, certain mundane/repetitive/trivial tasks really don't warrant pair programming IMHO. You're spending two brains on something that really takes 1/4 of a brain.
The ideal case for pair programming, IMHO, are those tasks where you can visualize the general path forward, but where there are significant challenges wrt implementation such that another pair of eyes can really provide insight. For example, say you have to implement a module, and you have a general idea of what it needs to do, but the overall decomposition and abstractions involved may be inchoate. While I think a fair amount of "implement this new feature" type of stories fall into that category, in my experience that comprises only ~40-60% of the total workload.
The above mostly applies to pair programming with two fairly equivalent/experienced developers. I agree with others who have noted that it's a fantastic training mechanism for new/junior devs. And then, there are various special case scenarios that justify it, as in, you have a problem with X and need to pair with an expert in X to resolve it. IMHO, these are best done ad hoc rather than via a formal process.
> Because I have three logical registers on a good day.
That’s a fun way to put it. When encountering the usual brain–computer metaphors, I’ve always felt like I relate more to the Turing machine scanning over its strip of tape.
You don’t really have to fit things into logical registers before you can speak of them. If you stop trying to do that you will find that you can speak your mind directly, which requires a lot less effort. The recipient of your message is also a human mind and while you will lose the handrails of logical clarity you will gain the safety net in abundance of bandwidth and feedback loops.
I guarantee you, my mind does not work like yours and I need to translate.
If you want me to explain code as I see it, I'll start in the middle of a function, where you have no context what it happening and jump to another line of code that is two functions removed. Repeat. You will have absolutely no idea what's going on as I flip through tab after tab of code.
My brain does not like doing things in order. I have to force it. Hence the processing overhead.
My friends find it entertaining to listen to me tell a story, because none of it is in order. I frequently backtrack or go down "irrelevant" paths, before returning to one of several previous threads.
Fortunately for this comment and the second and third novels I'm working on simultaneously, editing exists.
It sounds like working on understanding your thought processes would be useful practice for people who want to learn to think and understand flexibly.
You seem to be explaining things from the point of view that your different way of thinking is a problem for others rather than an opportunity for them to grow and learn. That's kind of odd...
Personally I think it would be very interesting to work through code in that way, and I don't think it would particularly detract from my understanding.
That's because I spent a lot of time sitting down to explain how I think clearly while not overloading the reader with chaos.
If you'll indulge me, I'll try to explain using part of a story I wrote as an example. (It is a furry story, hence the animal body language.)
——
## My explanation
“You went grocery shopping?”
“About two hours from now.”
“You can relax,” he says after he sets the kettle down. His ears perk up, staring at me intently, and I steel myself. “I took the week off.”
“I didn’t expect you to be up so early.”
Then I notice the grocery bag on the table. Breakfast probably being oatmeal or toast; we were out of eggs.
“You okay?”
——
Who is speaking at each section of dialog?
1, 1, 2, 2, 1, 1
——
## Original
“Yeah,” he replies sheepishly. “You got three minutes to get dressed while I get your coffee.”
“You can relax,” I say after he sets the kettle down. His ears perk up, staring at me intently, and I steel myself. “I took the week off.”
He breathes out slowly, but his tail gets more frazzled. “And you were going to tell me this when?” he says with restraint.
“About two hours from now.” It’s my turn to look sheepish. “I didn’t expect you to be up so early.”
“Thought I’d make you breakfast.”
Breakfast probably being oatmeal or toast; we were out of eggs. Then I notice the grocery bag on the table.
“You went grocery shopping? Did you take your anxiety medication?”
——
Bonus round: What does “You okay?” from the previous section refer to?
There was a minor accident in the kitchen that let to this discussion.
——
This is a bit contrived and I mixed things up more than usual because understanding creative writing on paper is easier than explaining code over zoom.
I agree with this comment. Not all problems can be solved this way. Sometimes I need to sit down and think without constant interactions. Interactions are great but they have bandwidth limitations for the most part.
Echoed. I've done very limited task-specific paired programming and it's been okay, and I got enough out of it to see how it may be a good way of operating for some folks, but not as a matter of routine for me. It would be awful. I just don't approach problem solving in a way that lends itself to having to communicate what & why I'm doing something a certain way as I do it. It takes too long to explain. After the fact? Sure, I can explain and document quite clearly, but not while peeling the onion and sometimes boring through a few layers to come out of the current one at a different point. I don't think this makes me better or smarter, just a different method.
I think the GP post (GGP?) about the utility of sharing expertise is a good one, though I think that can be done w/o it being 100% all the time as well. It probably also depends on the nature of the tasks and complexity of the system. There may be jobs that really do optimize better w/ a lot of paired programming, and I'm just not a good candidate for those roles. We all have different niches in which we achieve our best performance.
Have an upvote from me and thank you so much for this comment. This describes perfectly my own state of mind. I've noticed having problems communicating my thoughts about my code in meetings, but simply could not point a finger at the exact reasons. But this describes it perfectly. If I may bother you, could you answer two questions?
- Were you officially diagnosed with ADHD. I never went to a doctor, but in the last years I had growing assumptions I might have ADHD or Asperger (or both).
- Do you follow certain strategies which made communicating your thoughts and ideas easier and/or better?
> Were you officially diagnosed with ADHD. I never went to a doctor, but in the last years I had growing assumptions I might have ADHD or Asperger (or both).
Diagnosed bipolar 1 recently. But I was diagnosed as ADD as a child thirty years ago. ADHD is a popular addition to the standard Bipolar feature set.
> Do you follow certain strategies which made communicating your thoughts and ideas easier and/or better?
Not in a way I can easily teach. I learned my social skills late and had to study people to understand them. I take all of the inputs and outputs of a known person and mentally visualize what their internal state is. Then I play out how different phrasing will be received.
Whatever part of the brain normally handles social interaction is broken in mine, so I use logical thinking to run other people's brains in a virtual machine.
Thank you very much for answering, although it is a very personal thing to ask about.
I guess I should get an official opinion. Nevertheless, diagnosed or not, virtualizing people seems like it could work for me, although it seems to take a significant amount of time for each person to work.
It took a lot of time to optimize the process. Once you get used to understanding people individually, pattern emerge and you can generalize a few things. I have a number of mental guardrails like: If (person) is (things), then don't express (idea).
IF my dad IS talking about (politics|religion) THEN do not enter discussion.
I'm at a mandatory-pairing-multiple-times a day place right now and I've made the same observations you are identifying here.
Pairing may be good to some degree for knowledge sharing but it works against good architectural design, which requires the kind of holistic thinking you describe, as well as kind of micro-iterative whittling away at the problem that interactive pairing couldn't ever achieve. In addition, the n^2 communication lines yield the worst effects of Conway's Law https://en.wikipedia.org/wiki/Conway's_law
Nearly all of the computational problems we face in industry (save a narrow class of specialty problems) can be pretty easily articulated in the "macro" sense: "oh, we'll just have this distributed actor invoke that one and he'll reply with the blah, blah state".
Look, we just paired and collaborated on a design, cool! But the reality is that none of the hard parts have been solved. The hard parts are always the unanticipated errors, edge cases, invariant violations that beset every system--a large set of issues that need to be made airtight when it comes down to actually putting the code and tests together, and these require the holistic thinking you're talking about or either you get subtle bugs or otherwise a mess is made in the code.
As an industry we've gone so hard on coming up with social processes to "knowledge share" (pairing etc) and do things like audit for defects (code review process), but all of these are ultimately compensatory measures for bad design and bad code; and, in fact, as you suggest, they kind of encourage and trend toward bad code.
A different approach to building systems socially would focus on the code being decoupled and articulated such that the barriers to entry would not _require_ pairing and these other processes. Decouple and compose components that can be understood at face value and in situ.
But this is very hard and requires extensive practice and expertise, something our industry isn't keen on talking about. We like that quick race to "expert beginner" wherein we can say "Phew, now I'm an expert". So instead of focusing on mastering these we go for least-common denominator processes, which if you think about it is what pairing, and many of our processes are,- least common denominator.
The truth is we're social creatures, so I don't think we'll ever get out of this state. Social processes will win not because they optimize the problem space but because most of us love and crave the interaction. My only lament is that we don't call the spade a spade and we try to argue that these processes are necessary for optimization when they really impeded optimizations and create downstream frustration and limitations.
IMO, pair programming is most useful for short design discussions and mentoring, like explaining a better way to architect a feature to a junior engineer. I look back on these experiences fondly, and this type of collaboration helped me grow a lot as a developer.
I don't feel like I get the concentration and focus required to "put the whole code implementation in my head" when I'm pairing, so I don't really see how it can be used 100% of the time to build systems efficiently.
And regardless of whether it's a good way to work or not, many engineers just won't want to have someone looking over their shoulder 24/7. That kind of environment would drive me mad. I need to be able to drown out the world and bury my head in the code, and most of us don't work on code the entire day. I like having the freedom to read an article or browse the web for a bit whenever I want to fuck off.
Pair programming and mob programming are definitely not for me, and there's no way I would take a job that requires doing either most of the time.
Good design and getting everything right up works right up until the requirements change and the design no longer meets the ask. Unsurprisingly, teams might not even know all the requirements when building something new. Having everything orderly up front is a pipe dream.
That said, there are definitely cases where sitting back and thinking through a design is a really good idea. In my experience, it's 1/10th of the job.
Good design can handle changing requirements, otherwise it isn't good design. Good design requires a lot of domain expertise and not just being a good programmer since you have to be aware of what kinds of things the system should be able to handle, but it isn't impossible.
By domain expert I mean someone who has worked in a single domain for many years. Lets say you have written healthcare backend software for 10 years, then if they tell you to design a new healthcare software system then you will be able to predict most future requirements the system will have even if they don't spell those out explicitly to you. Sometimes laws changes and you have to redesign stuff, but having to adapt code due to new laws isn't a common occurrence.
Edit: And 10 years in a single domain really isn't a lot of time. In a sane world you would be called an apprentice until you reach that level, that is the only way to make robust products. This is how almost every other field works, but in programming people seem to think that such expertise is impossible, at least at scale.
i have ADHD too, and have the same problems. In fact i'm assigned into one-person team in my company because i work effective in that way. My feedback is always 10/10 by my managers, but i think i couldn't work that good with such things as pair programming.
This is probably more a problem of expectations in pair programming than pair programming. It comes the easiest to extroverted people with "standard" thinking patterns that are mappet to language 1:1, I also have to translate thoughts into words which is more of an effort than actual coding. But you don't have to express everything with words, if I can see what you are doing I can just follow that. I can't imagine doing it always, but for onboarding and from time to time its great. Not just for knowledge of the system, but learning how other people flows are completely different, what tools they are using and how their workflow looks like, etc.
100% pair programming is not compatible with deep thought and concentration.
However, solo thought doesn't necessarily activate all neural pathways that will solve problems.
Much like explaining problems to someone else often causes you to realize the bug, social interaction activates communication, idea formation, recall, association, and error checking neural pathways that don't necessarily fire when thinking in isolation.
So for 100% pair programming: again with the dogma in IT. 100% code coverage. TDD. Strict agile/process alignment.
> Communicating with neuro-typical people is frustrating, mostly because I try really hard to communicate clearly.
> If this comment is a bit rambling, you know why. :)
Everyone has struggles with communicating clearly don't they? Do you think it is possible that we put too much emphasis on apparently typical and non-typical way of thinking, with one pathologised?
Would ADHD really be noticeable if we were living in a medieval agricultural society?
I'm speaking as part of a generation where boys grew up being medicated for what I saw over-diagnosis of ADHD.
The whole ADHD as an adaptation theory has been throughly debunked.
Your confusion is very understandable because most people don't know what ADHD is. Some of the symptoms overlap with immaturity, so people who are not qualified to tell the difference will frequently misdiagnose the problem.
(Note: I am not doubting in any way that you’re great at what you do and highly successful. Nor am I downplaying any difficulties and struggles you have had.)
My genuine question - Is it possible to have ADHD and be a coder? It’s just that coding requires so much focussed attention over long periods. If you are enjoying a career as a coder I’m inclined to think either the ADHD is mild or treated very effectively? Or even that treated ADHD actually makes you better than the median somehow?
It is possible, the condition is a bit poorly named. The video of the talk by Russell Barkley that is linked elsewhere is a good primer https://www.youtube.com/watch?v=YSfCdBBqNXY). People with ADHD can have episodes of hyper focus. However this is a bit a misnomer, it's called Perseveration and is not really a good thing, and has more to do with one's inability to task switch (https://en.wikipedia.org/wiki/Perseveration). However it also allows you to completely zone into a code base or a problem. The problem is you don't really have much control over what will catch your attention. But of course you can develop quite some deep technical expertise this way.
Now, that said, there is a new movie, Everything Everywhere All At Once, and if you take this title as a stand in for ADHD, maybe you can see that while this way of living can be overwhelming it also allows you to have a pretty good overview over systems and how their components interacts very fast. I think that's what many ADHD'ers are actually very good at, grokking code bases or the gist of things very quickly. Systems thinking in general. Also quick recall / association chains...
Also, on average, the higher your IQ, the later in your life your ADHD diagnosis will be (see this video on adult ADHD https://www.youtube.com/watch?v=dVDhYtQkuO8). Your other abilities can compensate somewhat for your ADHD. Also of course when battling this condition you will build many personal tools and habits that neuro-typical people will never have to do, so in that sense you also might have a leg up in certain situations.
I'd say professionally the biggest problem is not so much on a technical level, but more on an emotional / impulse control level. ADHD'ers can come off as brash, speaking their mind freely, not being able to just put that comment in when it's better to shut up.
Attention-deficit hyperactivity disorder is poorly named. It does not necessarily imply an inability to focus. It's essentially a combination of impulsiveness and poor short-term memory.
A person with ADHD will have a tendency to get distracted from the task they're supposed to be working on, and will instead work on other things. That's not necessarily bad if those other tasks are important. Perhaps counter-intuitively, the lack of impulse control may even lead them to hyper-focus on a task... just maybe not the one they were assigned.
People without ADHD also get distracted, but they have the impulse control to better resist tempting distractions, and the memory to remember to return to their original task after unavoidable distractions.
My entire view of ADHD changed when I saw a video for parents of children with ADHD a few years back. This is one of my favourite HN comments of all time: https://news.ycombinator.com/item?id=17889156
ADHD is quite badly named imo. It's not so much a deficit of attention but a disregulation. If you are interested in something then you can invoke an almost obsessive fixation on the task (hyperfocus I believe some people call it) which lends itself well to coding in certain conditions.
Sure. I've been diagnosed with very severe ADD and I've been programming since I was 8 (now 34), professionally since ~18. I took medication for ADD but have since stopped, as it basically caused me to sit for 9 hours and work with no breaks or food. I still have plenty of issues related to ADD, but I'm good at what I do all the same.
It has way bigger consequences outside of work for me. Things which you are very passionate about are easier to focus on than things you are not, regardless of AD(H)D.
Thanks for wording this so well. I notice it when a coworker asks for help, I usually have little idea how to help them when looking at the problem together, unless it's something obvious. But when I look at the code by myself, my mind is somehow free to explore it in "the natural way", and the answers may come quickly.
I don't have ADHD but I couldn't work 100% pair programming either. It's true, pair programming does an amazing job when it's about knowledge sharing, but I find it exhausting.
For me the optimum would be a few hours pair programming per day on tasks where it's the most beneficial.
You waste your time managing visual presentation (more so than 1D text). Schematic entry used to be commonplace for FPGA and ASIC development in the 90s. The industry has mostly moved to HDLs for digital logic because it is more productive and you get side benefits like revision control, easier reusability, and tooling independence. Anyone promoting 2D visual development for programming is selling snake oil.
I've found the opposite. An approximate quick and dirty visual representation can transport almost instantly the knowledge that writing back and forth for half an hour could never achieve.
When I learn about and talk about a system a visual representation of the flows of data and function calls is playing in my head. I get an overview of the system and what it does. Think "mental model". I "see" that this service calls that service to get that piece of data, which it gets from that database table and it all flows over there to do that and suddenly it all makes sense. I recall those high level flows for a very long time too and I have no idea how I do it. It just happens. I hope my mind keeps doing this for a very long time still.
I can talk about it and it makes perfect sense to me. There are other people at the company usually that share the same knowledge and understanding and if we speak a similar enough language we can communicate well. And then there are people that do not seem to get this level of understanding, even after prolonged periods of working on the same code base. Ever. When you ask them to explain to you how the systems and modules interact, they can't.
And then you draw some simple graphs of this service and that service, and this database here etc. and it finally clicks for them. They could not synthesize this from code or written text. They only ever saw the local view of the module they worked in. Overall, more abstract flow of information and modules was lost to them. You have to actually visualize it for them.
Note that I am not talking about "visual programming" as in drawing UML like diagrams and such to actually program. It's purely about showing data flow and call stack and such. Usually I don't need to draw this for myself as my head does it for me and it works really well with statically typed languages without any magic going on where I can just have the IDE navigate to exactly the right places, find all the code references quickly and accurately etc. One time (a looong time ago) I actually threw together a quick script to generate a graphviz file for the call graph of some system based on some proprietary database's stored procedures that I had to quickly come up to speed with and that nobody was there to explain to me. I think it printed out to like 15 pages that I taped up on the wall next to me just to make sense of it. No IDE support to click through from one procedure to the other.
Google “crazy conspiracy board meme” and you’ll have a good analogy for what’s happening. If I start writing it down, things randomly disappear from board. Which requires me to look at the gaps and fill in the blanks.
You can imagine what this looks like from the outside. My dad has interrupted me so many times with “get to the point” and the only response I have is “working on it.”
The funny thing is… I’m an author and prefer to work with text.
Yeah, for mind map style note taking I use hierarchical bullet lists. It's the same topology (if there are no cycles) without having to worry about layouts, and you can have both hands on the keyboard. I go up and down a lot and move blocks around.
As someone with ADHD and memory issues, your comment is what I hope my future looks like. Would you mind expanding on how you're able to work through ADHD symptoms, motivation issues and such?
- Learning how to have realistic expectations about what I can do day after day.
- Prioritize self-care and optimize for long-term performance over short term success. This includes going to bed earlier than I want. :(
- Working with my manager to have the proper accommodations. In my case, strict 40-hour work week, no work interruptions outside of that, and time off as needed.
I’ve needed accommodations less since things have evened out, but I’ll never be able to do on-call.
As someone else who struggles with these things, I actually found pair programming helps a ton.
Any time I get too distracted and drift off there's someone to nudge me back into focus. Occassionally I'll have to apologise and just say, "Sorry I didn't catch any of that" which sometimes takes a lot of understanding on their part to not be offended.
There are some days where I struggle to explain things which is very frustrating especially for architecture type issues. I also struggle to actually build anything from scratch, and definitely have a brain more wired for destruction than creation.
Secondly, you need to find an understanding workplace. The best places I've worked have been understanding of the fact that some weeks they'll get less out of me than a freshly hired junior because other weeks I'll do some very good work.
It helps if you can have a niche, and helps if you can start off making a good impression. For me that niche is more of a bug finding and security focus. On weeks I'm feeling very motivated I can spend my extra energy being useful finding security holes and general bugs. Good managers will see the value from that.
If you tasked me with writing even the most basic "todo list" web-app from scratch you'd probably find me after a week deep in analysis paralysis still deciding between frameworks having not written a thing, but give me the simplest "todo list" web app even one that's too simple to have bugs I'll have found something wrong with it before the day is out.
But everyone is wired differently, so your niche might be the building side. Just work out from experience what your strengths are and lean heavily into them, or at least strong enough to get a reputation than you're good at your job, but not so heavily you get pigeon-holed in a role.
And if it's just not working for you, don't be scared to just quit and find somewhere else. There are good and bad workplaces, and a surprising amount of advice is from people who have only ever worked 1 or 2 jobs at most so don't actually necessarily have the experience of different workplaces to be able to back up some of their assertions so take all advice with a pinch of salt and work out what works best for you.
Medication and note taking helped a lot with me. Even better, a good note taking app since my handwriting is garbage, right now I'm using OneNote and I keep it pinned to every desktop separate from my code.
Motivation- you need to actually align your tasks with an actual concrete personal goal or sense of accomplishment. And be invested in the work. Lacking that, you'll be dependent on external stressors to get anything done, which will reflect poorly on you if it gets to that.
Thank you. I do rely on medication and note taking apps (though mine are a bit scattered).
One of my issues with motivation is what you mentioned: I really really struggle to get invested. Things that are "work" seem to live in an anti-motivation bucket, regardless of how organically interesting they may be to me outside of a work contest. I'm in my 30s now, and I've been doing this my whole life and it is killing me. It takes a tremendous amount of effort and an extremely imminent deadline to get me to start anything. This (ostensibly) runs completely contrary to my self-concept and value system, but the motivation problem permeates every fucking inch of my life, and always has.
I can read this back and recognize a defeatist attitude, but I don't know what else to do.
In terms of overall mindset, I've found it helpful to think about my month as a portfolio of days. Some will be hyper productive. Some will be almost nothing.
This has helped in two major ways. I've let go of the idea that the hyper productive days are my natural state, and that the 90% of the days that aren't there are some kind of failure. I've also built my career to avoid having daily accountability and prefer weekly/monthly.
That mindset shift, separate from the daily "how do I get stuff done" tactics, has really helped prevent the kinds of negative spirals that adhd can put me through.
Awesome. I haven't optimized my career this way yet but accepting that some days I will code 16 hours straight, and other days I won't even look at my laptop has done wonders for my anxiety caused by seeing everyone with a constant productivity and seeing myself in this daily rollercoaster.
That just can't be more productive over the long term, though.
Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on the system. Maybe that takes two months? Or even six months? Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert.
Unless you have such incredibly high turnover that the period to transform a developer into an expert is close to or less than the average tenure of an employee, in which case your team has other issues that likely need to be addressed, because why are people jumping ship so quickly if it's such a great place to work? (For example: If it takes six months to produce an expert, you'd need to have an average tenure of less than or equal to six months to really benefit from pairing; anything more and the 50% performance penalty has to eat into your overall productivity.)
On top of that, I have never been at a job where it's taken me more than a week to get up to speed on a system, or at least to the point where I can simply ask the occasional question of the experts on a team to get me unstuck. Even if the average developer took a month or two, pairing beyond that point is simply fun and not more productive than two programmers developing independently.
Unless one of the developers is otherwise likely to produce negative productivity on their own, I suppose. I've worked with that kind of developer as well, and the right answer is to eject them from your team, not pay other developers to babysit them.
There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback.
Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles.
My guess as to why we don't see more adoption is 1) most developers aren't that fond of it, and 2) most managers do some quick gut check mental math and assume 2 programmers + 1 computer can't be equal to or greater than 2 programmers + 2 computers, that's nonsense, actual evidence be damned.
edit to add: I agree with commenters that pairing is more demanding/draining than solo work. I shudder at the thought of anyone trying to pair for 8hrs straight, or "all day every day 40hrs/wk". Nobody solo programs like that either though.
As others pointed out, for many of us pair programming is much more demanding on mental resources. The way I tend to work is by doing micro-breaks, checking out other things I would not be comfortable sharing with someone else; if I don't do that and keep hyperfocused, I get drained quicker.
Also you can get a couple of programmers that will go down the wrong rabbit hole for much more time because they reinforce their wrong belief mutually. This obviously happens with individuals as well but if you get the wrong mix it can be much worse.
Also to expand on this, personally I found pair-programming easier on my mind when done IRL and not remotely. Sitting one next to the other has just more bandwidth available and spreading the communication over it makes it way easier for me.
Remotely, I can do it for a 2, maybe 3 hour session and then I'm fried for the rest of the day (but usually those were 2-3 good and productive hours).
I've done "pair programming" a few times, with (I think) great effectiveness, but (a) it's been in a very specific context, where we each brought substantial but not-fully-overlapping expertise to the task (not pairing a newcomer and an experienced developer); (b) it was an entirely voluntary thing that the two of us decided to do, not something imposed on us by management; and (c) it was for short "sprints" of no more than a few days, not for extended periods.
If it became a required part of daily work in my company, I don't think I'd be around for long.
Pair programming for me works best on complex issues I, or others, have already failed at. Usually its a short term endevour (minutes), ive only done (hours) of pairing in extreme circumstances either during PoCs or prod issues.
My opnion is that people need time and practice to aborb. Everyone has there own way. If you are pairing everyday for no other reason then company policy, it sounds like the worse place in the world to work.
I don't mind pair programming but I don't have the physical/mental capacity to do it for a full work day. I can only imagine how exhausted I'd get after several weeks of it.
When I do pair, I only work for 3 or 4 hours that day total.
Pair programming is one of the smartest inventions in this field, but I wouldn't dream of advocating it for this reason.
The best model would be four hours of pair programming and another four of paying those programmers to take a long lunch, a nap and a walk. Those 4 keyboard-hours would probably be as productive as 16 keyboard-hours of the same programmers working independently for a full day, if not more. And unlike full time pair programming it would be sustainable.
I don't disagree, but like all business initiatives it's really hard to convince my boss's boss, that I should be able to sign off and work half the amount of hours for the same paycheck.
So we have to "play" the game of looking busy and appearing productive for appearances.
Maybe the best for you. I enjoy a couple/few hours of teaming up or conversation, and then a heavy rest of the day solid coding/planning/research with a lunch break and a few short water cooler meetings.
3 or 4 is just fine. I worked at a place that only did pair programing, but quite often we would break up to write docs fill out jira issues and do all the other stuff that's needed.
Recently we did 3 way programming once a week for 1 to 3 hours and it still had a lot of the benefits. Not sure being absolutist is a good approach to anything in our field.
Therein lies the problem. How much is an avoided bug really worth? A > where really a >= is needed is theoretically going to get caught with pair programming, but how do you make that a metric you can track when we still don't have any way of measuring developer productivity. We never got past the fact that measuring lines of code output is dumb, to any other sort of metric. Even if we had such a metric (using magic, perhaps), would programmers actually welcome it?
"Fewer bugs" needs to produce 2x productivity over the productivity of the two developers independently in order to actually be a benefit. Code review and using typesafe languages can also catch nearly 100% of those bugs as well, without the 50% performance penalty.
"Keeps people on task" seems like management-think adjacent to "butts in chairs in an office" requirements: There's a fear that someone might be "wasting" time by being distracted, when you seriously need to contemplate problems sometimes.
I'd need to see that "actual evidence" that we're allegedly discarding. Two programmers with two computers clearly could produce twice the productivity if they're both strong programmers. When I've been pairing with people I simply do all the work. I might get 1-2 comments per hour about a missing semicolon that I would have discovered the moment I tried to build. The claims of the pairing advocates are pretty hard to believe, and I don't see extraordinary evidence to back their extraordinary claims.
As I intimated above, the only way it would work is if the developers are junior (or mediocre) enough to be prone to contributing 0.5x or less productivity left to their own devices, so that the two developers' inadequacies at programming complement each others' and you get a 1.5x productivity out of them combined or something. And I do suspect that companies use that fact to hire less competent developers and make them at least reasonably productive; Pivotal does 100% pairing, and sells it hard, but note that they're paid per developer hour and so actual productivity per-developer isn't what they're necessarily what they wanted to optimize.
As to your Edit: The exact thing I'm objecting to is 100% pairing, which is practiced at some companies like Pivotal. Or worse, 100% mobbing, which is more than two people at one screen.
This may work for simple tasks and mid level work. For complex and exploratory work I hate it.
I've been programming at various levels of abstractions and different stacks for 20 years. I often have very good intuition on diagnosing and solving technical problems. It's very hard to verbalize this, especially to people without the same background, it's intuition built on hours and nights of pain and debugging/googling/prototyping and I often need to search and REPL/prototype things to know I'm going in the right direction.
So I waste time dragging the other person along my mental path, and when I go into a wrong direction the cost is also increased by having to explain what I'm doing + the other person usually being annoyed at being dragged along for something they barely understood and it ends up being for nothing.
One of threads is reviewing code as well, which would be done later on anyways.. among other benefits. I'm invoking commodore64 days for the second time in a row now - back then, during the war, as kids we didn't have much comouter lying around so few of us gathered around a single one and learned and tinkered with it. It was awesome since everything bounced out loud from multiple brains. XP in general is alright but maybe not all of the time, as with anything.
> Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles.
While I agree with that, the cost-tradeoff is not worth those improvements (which are slight). Feel free to post to the studies that you find compelling.
> There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0
No it doesn't, bugs happens since there is much acceptance for bugs, programmers develops just enough awareness of them to get the bug count to maximum acceptable levels. If you take two programmers who both learned to get there on their own and have them oversee each others work, you reduce the bugs temporarily, until they adjust their attentiveness and conscientiousness downwards to account for it and the bugs rise again until they are at barely acceptable levels.
You see temporary improvements like this happen everywhere. Researchers love it because it makes it trivial to publish papers, but these results usually doesn't scale, and even when they do scale the effect is significantly smaller than originally advertised.
(I know you run out of people in real world teams pretty quickly but) rotating pairs regularly helps with this, with a maximum of two-week pairings to avoid this and other issues.
Yeah, we can't expect that company to also post articles that show either less splendid (or negative) tradoffs of PP, now can we?
Meanwhile, some of that research is pretty easy to deflate. From the first article, for example:
Students prefer the 15% overhead
That's right -- they used a survey of student experiences to draw conclusions about what works best for senior developers well into their careers. As the authors themselves put it: "We feel that this is a strong indicator of the satisfaction of pair programming."
I don't see how they can call this "strong" evidence of anything.
True expertise on a large, complex code base does not just take a few months; competence is best modeled as growing over long timespans, not as something that quickly reaches an "expert"-level ceiling. This is all the more true when-- as is often the case-- the codebase is a complicated legacy thing, full of accumulated "technical debt" and unneeded complexity of all sorts. This is not to say that 100% pair programming is always the answer, but doing it to some extent is likely warranted.
This is exactly what I'm currently jumping into as a 'new' dev. I've been coding for about 3-4 years, am working on an ANCIENT php in-house ERP (we're still running v5!), and find the technical debt/unneeded complexity more shocking by the day. I've been in this position 3 months and feel like I've barely even scratched the surface of what is going on under the hood.
Teaming up for training is absolutely crucial at this time.
Having worked at both a mid-size EdTech company and now in a smallish part of Microsoft, every codebase for public-facing software that I've seen would take at least 1 year to achieve actual expertise in (while guided by an expert!) and would probably take much longer.
People forget what a creative profession coding is. The assumption that programming is a factory is what is being challenged. Most companies seem to have a factory approach and so you end up with technical debt weighing everything down to the point people just can’t get stuff
done and the job becomes
more about explaining why you can't do stuff.
To give a more concrete example a pair programming session might avoid putting in foundational code that ends up being a bad design choice and slowing down the team by 1% forever. Maybe at a cost of millions. That 1% will never show up in any OKR or KPI that just basically measures superficial stuff about the status quo (bugs raised per quarter, features delivered on time etc.)
I mean it is like we forget we live in an age where still someone smart coding at their laptop can launch a million dollar business.
If you can figure out a smart “hot take” way of working, like maybe pair programming it is a big competitive advantage.
To the point you probably wont find a job for a company that works that way because they can more than make do with a small team.
You are correct in that having two people both well-versed in both the system and the change they are making is a waste. However, that tends to be rare - the more common situation on a team with no newbies is that you will need to solve new problems with new methods, possible integrating with new systems.
If you have a team of experts, and you want to keep them all experts, it's much more economical to have two people learning the new code as it's being written. Theories about what might or might not be helpful have very little value until tried in the field.
> Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert.
You’re forgetting that it’s impossible for any one person to keep all the details of even a medium sized code base in their head.
I imagine the initial “planning” phase of implementing a change would benefit heavily from pair programming because it avoids the issue where you write a bunch of code to find out that it doesn’t work because of this one detail that you forgot.
For the learning (“knowledge transfer”) aspect, though, I think you’re right that it’s possible to reach a point where writing the actual code (not the design) as a pair is not worth it.
There's a trade-off between efficiency and robustness.
It may not be as efficient, but it can be more productive in the long-term if you're better insulated from staff turnover, for example. Making engineers more replacable could also contribute towards lower wages (more able to hire beginners and make them competent, reduce leverage of existing staff).
> That just can't be more productive over the long term, though.
While you can type a lot more by having two people type in parallel, some programming is much heavier on the problem solving aspect of things and those types of problems are sometimes completed more rapidly with two people working together than with two people working separately.
I still don't really get pair programming. Maybe it's my inner introvert, but it sounds really draining. And what about all of the non-programming time during the day?
I mean, today I spent time:
- Digging into the analysts dashboards for some time series that seemed off. Generated a plot from my own metrics stash, filed a bug w/ the analysts about the differences. Replied to some doc comments saying that I'd done so.
- Code review of a few changes.
- Write a quick jupyter notebook (well, colab) analyzing a different problem. Basically reading the data for an example into the notebook, writing a bit of code to visualize it, fiddle until I had some sense of what the problem was.
- Decide I should regenerate a dataset with some different processing. Spent maybe an hour doing the code changes and getting them reviewed. Then build the binary, run it to generate a dataset, then launch a few-hour processing job to see if it works better.
- Write some notes on how I should decide if the new version is better than the old version.
- Fire off email to a few people. Asked one person about existing viz tools, updated another about my earlier colab experiments and asking if they know of anyone who's done a similar analysis.
Out of all this, I think pair programming would have maybe been tolerable for a bit in the middle when I was actually making code changes, but everything else was either based on huge amounts of internal context or was completely ephemeral analysis.
I think I must be doing a different kind of thing. :-)
Pair programming only works when both people have similar mental aptitudes/personalities/types/processing-speeds.
The times I’ve been involved in pair programming it has been a disaster. I need time to sit there and think and process while the other person is getting bored and wants to keep going or they start to talk which ruins my thinking so I have to start over again.
Pairing is actually great in limited scenarios where one person is an expert and the other needs to ramp up quickly from their knowledge.
But at steady-state, it becomes a drain on efficiency.
In my experience, forced pairing is something that a small percentage of people love but it burns most others out. Every company I've seen try to force full-time or even most-time pairing on people has quickly lost a lot of their good developers. Although on the plus side, they at least have a system in place for quickly ramping up new developers as they join to fill all of the openings.
Even then, people are different. Pairing for me is good now and then, but I need time on my own in between to figure things out my way. It's like hybrid work, nice as an option. I once had a boss who tried to force me to pair program with him at his convenience to check up on me, had.
It's hard to be scientific about this because there's no control group. If we clone your team and forbid them from using pair programming, in 5 years, which team will allow new developers to hit the ground faster? Which will have greater velocity. Which will have better code quality?
Some downsides to pair programming I've noticed:
1) People can tend to jump to the first solution they find, in order to not look slow or stupid. This doesn't allow for time to refactor the solution.
2) It can promote a culture of "spoken-word documentation" where all information about the system is conveyed via word-of-mouth, and nothing is recorded. You can see how this isn't scalable...
3) Not everyone has perfect internet, desk setup, comfortable chair, microphone quality, monitor resolution, etc. and it can lead to one person mumbling and another just going "yup uh-huh yeah"
I'll add another: you tend to miss out on some of the inner workings of the system when you have someone there to answer questions instead of diving in and figuring it out yourself. Yes, in an ideal world you have both, but doing lots of pair programming makes it too easy to take the shortcut and just ask how to do something, instead of learning the fine details of the system such that you don't have to ask those questions anymore in the future.
I’m the type of programmer who likes to shut themselves away from the works in silence while I work.
However one of the most successful complex fault tolerant distributed systems projects I ever worked on was done in a team of myself and one other guy, delivered in about 9 months from start to finish, is still, as far as I’m aware, running flawlessly years later and was developed through 100% pair programming.
We did it be css use as a team of two it was important that both of us were intimately familiar with every line of code and understood every decision made, but it turned out to be an incredibly effective way of developing complex software.
Some things to note: you have to get on very well with the other person, or it’s going to be frustrating. You have to have similar standards and ideals or you will clash and fight. It’s an exhausting way to work and you will need to take regular breaks. You need to be strict about the roles and about swapping roles regularly. We did a lot of remote pair programming (voice call + screen share that allows input from both: we used screenhero when it was still a thing, VSCode has shared editor support nowadays that’s not bad, not sure what other tools there are)
Other people mentioned ADHD, I too have ADHD and this definitely isn’t my natural way of working. I even had some resistance to it most mornings and had to tell myself ok let’s go. And it IS exhausting, you need a lot of regular breaks, you need to be able to shut off and not think about work at all after hours or at weekends, it is a very tiring way to work.
But DAMN was it effective. I don’t think we could have delivered it in 9 months, let alone without known bugs, any other way. We would not have both had the same level of understanding of the entire system.
I've done pair programming as the senior developer often at a previous job.
It sucked.
I paired with a young woman fresh out of a boot camp, and at first I was excited to do it because it was nice to have another woman developer. Yet she was just so threatened by me or insecure about her experience, she started gossip about me. Just awful
Another time it was with a mid level middle aged man, he just had a huge ego and felt the need to question single thing I did.
Honestly the best pair programming experience I had was with a "sports bro" type. I always wonder if it was due to fact coaches are a big deal in sports.
I refuse to do pair programming these days if I can avoid it.
So is retaining engineers, so that, once they learn the system, are available to maintain/teach it, and more importantly, are invested in doing a good enough job, because they will have to be around to deal with the fallout, if it was not a good enough job.
There's no one answer, but I'd suggest that having an environment that retains engineering talent, and incentivizes good, long-lasting work, could be helpful.
We do pair programming. The issue is that all of the developers that knew our system left a long time ago.
NOTE: this next part applies to the US.
Why? Developer salaries went vertical when COVID hit. All those Silicon Valley jobs became remote with big fat salaries and companies took months to respond, and many did not respond at all. The job I started last year I would have left if it weren't for the fact that I work well under 40 hours for a 6-figure salary.
If you are getting paid less than 100k/year with at least 3 years of experience, find a new job. Don't treat your job like it is your life. It isn't. They would fire you if they knew they could have someone do your work for half the cost, so don't let them "use you against you".
Things happening "always" or "never" are usually the cause of discomfort. Hard rules about 100% pair programming or opposite make things worse in long term. Starting with a "buddy" on team/ work switch almost always helps. After that, it's mostly 'it depends' thing. We must be conscious about what works best for the individuals and teams and should settle around the the sweet spot. Excess of anything is unhelpful.
> a place that did 100% pair programming with rotation every day
Sounds like a nightmare. I interviewed once for a company where the team did exactly that, and it was the moment in the interviews I realized I don't want to work there.
ad-hoc peer programming is perfectly fine. Debugging something tricky or helping someone ramp up is great. But peer programming as-a-process is literally peer-micromanaging and outright insulting IMHO.
That developer was not hitting the ground running. That developer was being carried by someone else in speed lower then that someone else normal speed.
And also, pointy haired bosses and accountant don't mind pair programming all that much. Normal average developers with normal average psychology do mind it, object it, hate it.
I work in a team that leans heavily on pair programming and it's a night and day difference for productivity.
Besides the domain and system knowledge sharing, besides exchanging productivity tricks or new ways to solve problems, it is much less distracting. I strongly believe that on any non-trivial task pair programming accomplishes much more business value (more tasks done) and growth than having the two developers working solo.
I don't think it should be the only way to work, definitely not most of the time and it should be encouraged rather than mandated.
No, you won't "get to speed million times faster" by getting answers immediately. You have to learn system before you can ask sufficiently important questions.
I recently learned that some database system, internally, always performs two operations in the specific consecutive order. It was quite critical for my task at hand and no-one on the team was able to answer this precise question about the order, including team leader with deep historic knowledge. I had to read code, I had to prove that this sequence will be exactly as I need in cases that are important for me. And I read and reread the code before that "proof process" even to get the understanding that I can implement my solution if I can guarantee that order somehow.
"All easy problems are already solved", if I may quote fortune program.
The hard problems take time for research. By doing that research yourself, you learn how to do research, you learn code better and, finally, you are not doing research with someone who, well, may not know solution for your problem and may not even have a clue on what may help you with the solution.
The last point means that you are not wasting someone's time and you are not wasting your time too.
You say "A team with one expert and pairing is now a team full of experts" and I cannot agree with that for any problem domain that requires any kind of research.
> When I worked at a place that did 100% pair programming with rotation every day
Putting aside whether or not it actually makes you more productive, that sounds awful to me. Part of the reason I work from home is so that I don't have to constantly interact with my peers, and can put my head down and concentrate on my work without having my train of thought constantly broken. I have no problem with pair programming as needed, but I would never work at a company that forced it all day. To each their own, though.
The studies I've seen about pairing show that it's OK for beginners or lower-skill developers, but absolutely less productive for expert/senior developers.
Right, if you have a really good friend who just clicks with you pairing is great. But that isn't how pair programming at companies is done, they put you together with some other member of the team and tell you to do work, you didn't choose each other you just happened to be there and now you have to be mentally intimate with each other.
But you are right that voluntary pair programming can be a good thing, so we shouldn't ban programmers from pairing if they want to. But the discussion is whether it makes sense to force programmers to pair program. I really doubt that for example pairing John Carmack and Linus Torvalds would be productive, and that is the kind of personal pairings you get at work.
That's documenting an emergency, all-hands-on-deck response to a crisis.
I absolutely can pair for such an event. I'll pair for knowledge transfer. I'll pair for fun. If every second counts, or if the goal isn't maximum productivity throughput, the sure, pair away.
My point is not that it can't help for world-class developers, but rather that two world-class developers working on routine coding are absolutely not more efficient than two world-class developers working separately.
And people who advocate for pairing typically advocate for 100% pairing. Which can be fun but it won't be more than 2x as productive as two world-class developers working independently.
I would say that there is still a benefit of pairing an expert with a novice now and then. Not for productivity but for long term effects. They cannot be _too_ far apart though.
Occasional pairing, especially for knowledge transfer, is great.
It's the 100% pairing, or worse, 100% mob programming (up to six people with one screen!) that I can't believe would ever be more efficient than the programmers working independently.
Sure, have a party and mob-program for fun for an afternoon, or solve a particularly sticky problem that way, or use it to transfer knowledge about the system to the wider team. Have a blast, and teach everyone something useful at the same time. By all means.
Just don't pretend (as pairing/mobbing advocates do; not you) that two people sitting at a computer can be as efficient at day-to-day coding as two people coding separately, unless at least one of the two is a junior or near-incompetent developer who would contribute negative productivity on their own.
I need to quiet space to think (or at least thick headphones) to solve hard problems. I can’t understand how some people work without ever getting that. Do pairs agree to shut up until someone gets an idea?
I am not sure everyone has the same idea of pair programming.
I have never done it but it simply seems like: 2 people solve a single need.
How? "Deploy personal + company resources as appropriate to get the job done together" - however they damn well want to in that framework. It is between them. The pair could:
Use a whiteboard for 5 minutes every 3 hours and go their separate ways otherwise.
Sit together hunched over a single laptop.
Work from two entirely separate locations with collaboration software so they can see each others cursor and typing as they voicechat.
I mean, isn't it all about simply getting along and getting a job done?
> Do pairs agree to shut up until someone gets an idea?
Hard problems are quite rare, most development is mundane.
When facing hard problems, generally related to non-obvious bugs, there are many ways to solve them, and yes taking time off to think about it separately is absolutely one of them.
The issue with pair programming has always been that some people hate it with the heat of a thousand suns. I’m one of them. Its very effective I don’t dispute that, but it makes me absolutely miserable and I’ll end up quitting to avoid doing it.
It sounds like a small project where everything can be remembered by everyone uniformly and perfectly and also people with specialty and exceptional talent into one or the other area are laid off, and everyone is uniform in level of capabilities and preferred area of activity (so it doesn't matter who sits with who over what). Sounds too idealistic where it never happens that two come together who are equally weak or even clueless of a big legacy code and it never happens that the session becomes a guessing game. : )
Pair programming is fine in learning but the team of uniform level experts is too much of a fairytale idea to me for a generally useful concept in the complexity of life (and projects). Don't blame the pointed-haired bosses and accountants alone if the variety of workforce and projects, life itself (differences, variations, uncertainties, logistics, economics, ...), speak against the precious pair programming here and there and it will never be a 100% soluion for everyone and everything. Except if you eliminate/refuse situations with opposing aspects rigorously and without mercy of course.
As an IC I had spend so much effort in knowing the system. My pointed hairy boss has to know how hard it is to know my value. The only way he knows is to compare with others who take similar or longer time to implement similar feature. With pair programming I will speed up my coworkers at the cost of my pointed hairy boss thinking my job is easier and I am the one who is less capable.
This sounds great if you expect high employee turnover, but by that point, I'd be investigating the reasons for that rather than only addressing the symptoms.
I like that description of pair programming - articulates the benefit clearly. Makes intuitive sense & haven't seen anyone explain it that clearly before.
> accountants will never understand this
Oh...I take it back then.
I'm an accountant. Apparently I didn't understand this, so I must have been mistaken in my above assessment.
Paired programming is bogus. It is enforced by MBA types that are trying to get every last ounce of productivity out of us and forces you into uncomfortable collaboration scenarios. Our jobs are extremely difficult. It should be done at our pace in our environment, not theirs
Having been on both the knowledgeable and noob side of this "pair programming onboarding", I find it to be fantastic. When furiously googling / grepping around the code to self-onboard, it is so difficult to see the bigger picture of how the system works; if someone can explain the architecture to you, you become much more self sufficient, very quickly too.
On the "mentor" side of such pair programming, it is extremely useful to have to verbalize things that you may have gotten away with only fuzzy knowledge of previously. When the new hire asks a question that makes you say "oh wow that actually is quite broken!", you win as well!
Explaining the architecture in the abstract and explaining the architecture while changing something to the application are very different things. Both for the explainer and for the person trying to understand and process the explanation.
That sounds effective but I wouldn't want to work there. I do pair programming but on an as-needed basis. I find it very effective in short focused bursts but I couldn't imagine doing it all day. I would go insane.
I like situational pair programming, but there's no point in forcing another senior developer watch me e.g. set up a toy repo to track down a bug, when we both know what error I'm currently getting and what I'll be doing. You have to be able to pair when you need it and stop pairing when you don't.
For me, pair programming carries the implication that you're always doing it, which seems almost as bad as never doing it.
exactly. I find it vastly more productive to just be available at the drop of a hat to talk someone through an issue. once it gets to the point where we've decided on next steps, we can work on our own until one of us feels confused or something interesting comes up.
yes - lets talk frequently about the work and what makes sense
no - me watching you type and making off-the-cuff comments to keep myself busy
Maybe the sweet spot is to have someone pair with an expert when they are getting started and when they are struggling to understand things. Personally when I pair program I use a large fraction of my brain to interface with the other person. This leaves me much less brain power to work on the actual problem at hand. And it's far more exhausting to me than working alone.
Haired programming is bogus. It's just another form of micromanagement invented by MBA types. They're constantly trying to make us more productive and forcing us to collaborate in uncomfortable ways. Our jobs are difficult, it should be done at our pace, not theirs
Possibly dumb question, but... why do orgs need specific pair programming policies at all. Why can't you just ask questions and help each other as needed?
I know I'm going to get jumped but let's be real it's a cult behaviour that originates from the cult of extreme programming ("XP").
Some of them advocate for 100% "mob programming" (3+ people working together).
Doing it on a "as needed" basis is common sense and doesn't need a buzzword name either. It's what people have always been doing. But to push for 100% of it is insane and insulting to the individual.
One side effect of pair programming frequently is it probably helps make you perform much better during job interviews with coding and system design questions.
