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.
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. :)