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.
He argues that the biggest determinant on whether maintainers on a system they did not build will succeed is whether they will have access to the original developers: "The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and correction of errors in them, is essentially dependent on a certain kind of knowledge possessed by a certain group of programmers who are closely and continuously connected with them."
See also Bill Thurston's commentary on the nature of mathematical knowledge:
"mathematical understanding does not expand in a monotone direction. Our understanding frequently deteriorates as well. There are several obvious mechanisms of decay. The experts in a subject retire and die, or simply move on to other subjects and forget. Mathematics is commonly explained and recorded in symbolic and concrete forms that are easy to communicate, rather than in conceptual forms that are easy to understand once communicated. Translation in the direction conceptual -> concrete and symbolic is much easier than translation in the reverse direction, and symbolic forms often replaces the conceptual forms of understanding. And mathematical conventions and taken-for-granted knowledge change, so older texts may become hard to understand.
In short, mathematics only exists in a living community of mathematicians that spreads understanding and breaths life into ideas both old and new."
Mathematics is by far the biggest and longest running open source project on this planet and we are absolutely able to traverse it by centuries or millenia. This works across languages and cultures.
Mathematics is built on a small set of axioms and everything else is defined on top of it and proved.
Your comment makes it sound like there is some magic knowledge linked to arcane symbols, when mathematicians are the least interested in symbols and labels, they care about definitions.
As with any field if you get in highly specific topics then obviously you are going to lack enough literature and tradition on these topics and something may get lost, but if everyone forgot all they knew about math today we would be easily able to get back to where we are in a just by reading.
I work in the field of cryptography and I agree with GP, papers and research goes in all sorts of direction, but very little actually ends up forming a solid branch of knowledge. Sometimes if people aggregate into such a branch, there’ll be SoK papers (systemization of knowledge) that will start popping to make the tip of that branch understandable, and at some point people will create all sorts of resources including university courses and textbooks. But that’s rare, and it demands a lot of hypes, and sometimes tips of branches just go overlooked for a long time. If the author dies or move on, it’s possible that nobody can really take over the work easily, because there’s no proof, or nobody understands it, etc.
Afterall, this is what happened to a lot of famous mathematicians. Their texts were forgotten, and then rediscovered a very long time later, and sometimes proofs could not be recovered for a long time (cf Fermat)
Agreed that the amount of knowledge that gets systematized into papers, textbooks, and courses is a small subset of the total knowledge in a field, which is largely contained in brains. Although regarding your specific example: I believe the current most popular hypothesis about Fermat's Last Theorem is that he did not actually have a proof; it's very likely the proof he thought he had contained errors.
> Mathematics is by far the biggest and longest running open source project on this planet and we are absolutely able to traverse it by centuries or millenia. This works across languages and cultures.
This goes against what I understand about mathematics. I've tried to break it into a few sections.
Open source:
Things in mathematics once defined, tend not to change, even when changing would be beneficial.
Open source software tends to be a bit more malleable, but even long running things that can't change for fear of breaking things like POSIX or the X Window System end up getting alternatives that the industry slowly turns towards.
But mathematics just stays stuck. Multiple subfields will end up using the same glyph to mean two different things and when those subfields intersect it gets very bad very fast.
Even small quality-of-life fixes never end up getting accepted into use.
Another example (if you're interested in going down a bit of a rabbit hole) is the history of vector algebra vs quarternions. We ended up going with vector algebra, then learned that quarternions were actually better, but we continued to teach / and be taught vector algebra.
> we are absolutely able to traverse it by centuries or millenia
Well, this seems easy to disprove since knowledge does get lost and things keep getting rediscovered.
For example, Calculus was rediscovered multiple times:
- Archimedes (at least part of it with his method of exhaustion)
- Leibnitz / Newton (separately)
- and recently: medical doctors rediscovering integration and publishing papers on it in the 90s.
Other famouse examples would be Fast Fourier Transform, and perhaps Fermat's Last Theorem
> We ended up going with vector algebra, then learned that quarternions were actually better
Wait, what?
I'm still mostly familiar with assessments like "Quaternions... have been an unmixed evil to those who have touched them in any way" and "quaternions appear to exude an air of nineteenth century decay" (but not actually familiar with quaternions beyond a vague understanding of them as kind of 4d version of complex numbers).
But it is way less work than it took to build the knowledgebase we have today. Imagine if we could give all our math literature to the Romans 2000 years ago in a translated form, do you really think it would have no effect? Calculus was invented just a few hundred years ago, it took humanity millennia to get where we are today.
We started from the assertion that if a software project loses all of its devs it will not be maintainable anymore by new hires.
Not only this is far from a general truth, we all maintained codebases we knew nothing about I guess, but it applies even less to mathematics, which is a language based on definitions built on few concepts rather than vague and buggy business requirements.
> We started from the assertion that if a software project loses all of its devs it will not be maintainable anymore by new hires.
I recognize that this is due to my imperfect summary/introduction of the paper, but it doesn't make that assertion. I highly recommend reading it; it's not that difficult or technical.
I've maintained systems where I could talk to the original developers, and I've maintained systems where I couldn't. I know there's a difference in outcomes between the two cases, but I wouldn't say the latter is "not maintainable". Certainly buggier and slower to develop against, though.
Mathematicians die but their papers lives on. Newton discovered variational calculus, but at the time nobody else in the world understood his work so it was forgotten for a century when he died. But it was later picked up again. It might take a while, but it isn't the same thing as the knowledge not existing.
That paper is amazing. Completely changed my view on programming. For those who find it a bit inaccessible (as I did on my first read), I wrote an article about it a while back, explaining it further and giving real-life examples:
>The main value of a software company is the mapping of source code and problem space in the developer’s heads [In linked article]
That is a profound conclusion to reach. For the most part, I think it's true.
Without someone who wrote/fully understands source code, for example in abandoned software, the source code is a treasure map, the as-built plan of a building. It takes a lot of time and effort to orient yourself with things and make reasonable guesses as to what is going on. This aligns well with the original post.
A former colleague sent me an receipt that had an error from a system we worked on years ago (2 and 3 companies ago respectively). I bet we could tell the current devs where to find the bug pretty easily as we wrote a lot of that code.
We see something similar with our customers. When our customers have some new projects or change their ERP or whatever, we almost always know better than they do how their systems and procedures work.
Like, if they come with a change request we might ask what about X, they'll get all surprised saying no we don't do X, but after a bit of prodding sure enough, they discover they have a worker that's handling X every day.
This is simply because we've been around, while they've had multiple new persons cycle through their departments. When they change the ERP system, we've still got the guy who coded the integrations with their previous system.
In my experience, the biggest obstacle in understanding the system is that the underlying business process is not properly documented. A technical system is only as good as the business system it's implementing. Knowing the business process makes it much easier to understand the technical implementation, especially if you're trying to find bugs in the technical system since you can more easily see the mismatch between business and technical processes.
But hey, that's just me. And it seems clear that most businesses do a poor job, or don't care at all, when it comes to documenting their processes. So I guess I'm the odd one.
Heavily agree. So many times rewriting a feature from scratch is faster than figuring out from code, and there is a lot of really hard to understand code out there.
I remember once in a consultancy job for a bank having to maintain a form with a file uploader made of dozens and dozens redux actions interwhining in the most complex way one could imagine. There were atleast 4 folders of sagas.
No one could understand the code, I fought it a few days before deciding to manually document its cases by trying all input combinations I could think of and just rewrote it fromscratch in less than 250 locs. Took me an afternoon to rewrite it and do the maintenance task.
If I had e2es since the beginning I could've figured it out sooner..
Yes! And I love it when the business says they want to innovate, or improve efficiency, but they aren't willing to document and analyze the business process. Sure, we can implement your process as you communicate it to us, but I wouldn't call that innovative. Innovative would be modifying to process to take advantage of some new technology or model.
I disagree with this (sort of) for a couple of reasons:
1. For one, I think it's hard enough just to keep technical documentation up to date. Keeping separate business process docs up to date with code feels like it would be a collosal task.
2. That said, most software at least starts with some amount of requirements (whether that be a formal spec or a bunch of Jira epics). I have rarely seen any engineer start first by reading all of the old business requirements before trying to understand the code.
3. Even if the business requirements were documented perfectly, I rarely find that they are the major issue with understanding a code base.
Business data / process flow is so stable compared to a software implementation that having quality documentation pays dividends again and again. If you could document only one thing, document the business data flow.
Some industries are subject to control audits. So documenting the processes serves two purposes.
If the business doesn't know their process well enough to document or explain it, don't you think there will be water effort and rework, especially for edge cases?
Isn't coding basically documenting the business processes? (just in a way/language that computers can understand and read). Why document it twice? That's just violating DRY/SRP no?
I've found that for most systems, there are three great ways to "figure it out".
* Start from input. (Browser, API, whatever starts a process.) Map from there.
* Start from data storage. (Database, flat files, whatever.) How does state get persisted?
* How does the system move into production? If you can make a small change (even adding an innocuous comment) and see it all the way from your machine to prod, you can iterate and start to map the system.
A couple of things I found helpful along those lines:
* Data storage: what does the schema look like? Even if it is not persisted to a relational DB, is it possible to draw out a schema of a data model and all the relationships ("JOINS")
* Add logging to code you are trying to debug but are hard to understand and repro bugs for in production. Once you have logs about the full state that reproduces the error, the issue will be easier to fix. Don't roll out a fix before fully understanding an issue. As a corollary to this: always add a task to remove this verbose logging you added once the bug is fixed!
I worked with software where you could change logging level dynamically, per subsystem.
The ability to switch to DEBUG level, get a wall of text from a problematic spot, and switch it back to WARN was very, very helpful for troubleshooting prod.
Chiming in that this applies to controls engineering as well (think PLCs). Start from the IO, cross-reference that through the rest to get a feel of chains of causality and how it all works. Oftentimes it's critical to go from zero to applying changes as quickly as possible when unfamiliar (and poorly documented!) machinery is down.
> * Start from data storage. (Database, flat files, whatever.) How does state get persisted?
Reminds me of Fred Brooks' famous "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." quote
I get the impression that there are many professional developers who have never actually seen good documentation at any point in their lives. So many organizations think that having all of the functions listed in on a Javadoc page is somehow the same thing as documentation. And they wonder why it takes a new developer months to become productive..
And then you have the common argument that comments are bad practice. If I can read 2 lines of comments for every 20 lines of code while navigating a large codebase until I find the code I really need to dive into, the productivity gains from that are nothing to scoff at.
Writing self documenting code alongside comments makes things so easy on people who have to understand your code later on.
I have gotten quite a few comments from former co-workers who have taken over some of the projects I was lead on about how easy it was to read. That brings me a lot of joy, knowing that I made their lives easier and that the output of the trade I invest so much time and energy into is appreciated by my peers.
That said, I think `self-documenting code` is the bare minimum in 2022.
At my current role, I'm pushing the org to become "documentation first"--but this goes way outside the scope of writing code.
It's about writing all 4 types of documentation[] as a daily practice. This way, when you create something or learn something, that gets documented for the next person. It's not just about what variables and functions are for.
It's about what the business is doing and how that relates to our work, what our poor backend-cum-devops folks are having to do day in and day out, and about helping everyone accomplish their tasks without needing to go around getting help from 3 different people over 5 days because the system is completely opaque.
There is a minority of developers who believe that code can and should be mostly self-documenting, and that comments should be avoided because they become outdated and nobody reads them anyway.
I 100% agree that code should be self-documenting. I sometimes create intermediary variables or extract 1-2 lines of code into functions just so that the code can be understood just by reading the names of the variables and functions.
But there is also information that you can't just describe into the code. There are the examples I already gave above. Another one could be what I did this afternoon: I had 2 options to solve a problem, I chose the more complicated one but the one that works in every case. I added a 4 lines comment describing the second option and why I didn't use it. There is no other way to add this information that would be useful for me or another developer in the future other than a comment.
I've had to do exactly this. I sometimes write some code then realise that anyone less familiar with the details would look at it and see an "obvious improvement" which introduces a subtle bug.
At least once I forgot to add a comment in such a case and luckily I got the question of "why not just..." in the code review.
Note that their bad example is comment-every-line style just like GP's example.
No-comment self-documenting code is largely a backlash to this style, which is how introductory coding courses teach (taught?) was the right way to do comments. For a lot of programmers who first started in in one of these courses it tended to stick because they were never taught another way.
My algorithm for commenting is simple: If I don't understand what a line of code does, I delete it. If the behavior stays the same then it shouldn't have been there in the first place. If removing the line breaks something I put it back and add a comment explaining why it belongs there.
Yeah this is impossible because code that isn't written cannot document itself and then the only option is to have a comment. And sometimes the meaningful thing is exactly what doesn't exist. For example here we're not doing X because of Y.
I have found that I almost always benefit from a comment for each database table / model. The name can be somewhat descriptive but often its generic enough that its hard to tell if it specifically works the way I assume it does.
Yeah, I don't even know what "self-documenting code" actually means. You don't write README.md, ARCHITECTURE.md, JavaDocs, etc, at all? A new developer is supposed to go through all the codebases and figure out for himself?
>You don't write README.md, ARCHITECTURE.md, JavaDocs, etc, at all?
Maybe? Not sure - haven't worked on enough big projects to declare answer
>A new developer is supposed to go through all the codebases and figure out for himself?
Yes to this bit - code should have very clear structure to it with appropriate comments attached, whether that's literate style as JonesForth<https://github.com/phf/forth/blob/master/x86/jonesforth.S> shows, small section header comment or whatever.
It should be very clear what section exploring does - tiny example but cat<http://9p.io/sources/plan9/sys/src/cmd/cat.c> from plan 9 very simple segmented code - deals with file opening in main loop and cat function just reads and prints text
Self documenting code means carefully choosing names and structuring the code in a way that there is reduced ambiguity and maximum clarity instead of compensating for low quality code with additional documentation.
If your code is sufficiently clear there will be nothing left to say in the comments, the comments will have to repeat what the code is already telling you which significantly diminishes the value of comments.
>You don't write README.md
I don't think people are talking about self promoting projects or self documenting projects.
>ARCHITECTURE.md
or self documenting architecture.
>JavaDocs, etc, at all?
or self documenting libraries.
Seriously, what's so hard to understand about looking at code and then understanding it because you read it instead of having to read comments to understand the code that is in front of you? You seem to be under the wrong impression that self documenting code is a negative process where things are taken away rather than added.
Things are in fact taken away. Code as a language doesn't tell you why it exists. It only describes a process, not the purpose of that process.
And unless your programs are formally verified this process that you have codified most likely will not meet the requirements to satisfy the intended purpose.
A typical non-technical "assignment" that's given before someone is fluent is to describe in excruciating detail/list of steps how to make a peanut butter and jelly sandwich. The point of the exercise is to show students that you need to remove all ambiguity. Or at least as much as possibly. What the exercise doesn't show is.. why are we making a list of steps to tell someone how to make a sandwich.
“If you give me six lines written by the hand of the best debugging programmers, I will find something in them which will hang his operating system.”
The downside is those two lines of comments might be outdated and no longer match the code they purport to document, which can mislead you into believing something incorrect about how the code functions. I've seen that happen a lot.
I'm more than half convinced that the comments shouldn't be in the code itself but attached as metadata to the commit that introduced the code in question, with the further implication that every commit should be focused around a single idea that lends itself to a single coherent narrative.
The big drawback (right now?) is that diffs are computed on a line basis rather than a semantic token basis, so a bug fix for a comparison operator obfuscates the raison d'être of a whole conditional.
I think the tendency for devs not to document what they're doing betrays a lack of empathy for their colleagues. When you write a system, you are now the world expert in that system. Why not write a few words to explain the system? Save an hour or two, each, for everyone who needs to maintain your work? Why not link to the docs of the dependency you choose to use, or the forum posts or white papers that helped form the idea?
I feel like if there's good documentation, you don't need me. Similarly, the best leverage I can have is improving documentation or making documentation unnecessary through better interfaces.
> Similarly, the best leverage I can have is improving documentation or making documentation unnecessary through better interfaces.
I used to be a big fan of doco and still am. But a founder once told me that it is better to have intuitive UX (which obviates the need for documentation) and that rang true.
Wow - is nobody else bothered by all the empty precision?
57.62% Comprehension, 23.96% Navigation...
Even the piechart labeled "True effort required for many large-scale systems" says 7% of "effort" is Integration Test, and 8% in Module testing...
Want to raise my hackles? Give me statements with lots of precision but lacking in documented (not to mention repeatable, reliable, or robust) accuracy.
Convolved on this numeric silliness are several cartoons of smiling faces with vapid captions like "The figuring out time is a decision making time" or "Assessment is the process of understanding a situation around a system enough to make a decision".
Those numbers come from a peer-reviewed paper and it refers to the data they found in their specific experiment. It is not argued that those specific numbers appear in all cases. However, that data happens to be consistent with several other similar experiments done over the past 20+ years.
The rest of the short article builds an arguments based on the assumption that at least 50% of the development time is spent figuring the system out. If you find this assumption to be off base, please disregard the rest of it.
In any case, I'd encourage you to ask peer developers if they find that they spend 50% or more of their time reading textual artifacts as a way to figure the system out (code, logs etc).
I’ve always been fascinated by the glamorous toolkit project. Their ambitions are fascinating and align closely with software I’ve daydreamed about on more than one occasion. I wish I was more comfortable with lisp, or that it was compatible with Svelte/Typescript/Deno/Tauri which account for 90% of the projects I work on. I hope projects like this and Enso[0] are early iterations of what IDEs will look like in the future. There is so much room for innovation regarding ways to extend and augment the text formats used to author and represent software systems.
This sounds intuitively correct. It also leads to the unintuitive implication that paying down technical debt as soon as it arises and keeping systems simple and elegant as much as feasible, and well-documented wrt. inherent complexity, is not just key to software assurance and quality in general, but also to optimizing the use of developer time. Accidental complexity is not really manageable "debt"; it imposes large and growing costs over time.
Maybe one slight variation, that I think still agrees in principle, is considering 'the cost of doing this now vs cost of doing it later'.
Sometimes technical debt is isolated and handling it can wait until the next time that code is touched. Often people may use this as an excuse.
But there are a few cases where you can just wait and it won't be harder to fix later. I suppose this is the real form of debt that people should be referring to when they typically think of technical debt. It's debt with a next to zero percent interest rate. Just borrowing a bit of time now from future engineering time.
A lot of technical debt that is left is the kind that carries a few thousand percent interest rates and can quickly tie an organisation in knots.
The problem with abstractions is that it seems that not making leaky abstractions is difficult for most people (most people making these abstractions don't know about the concept of an abstraction leakage in the first place)
That they don't even teach 'leaky abstractions' is a bit rich, and as you point out it's hard.
And it's not 'hard for most people' it's hard for everyone.
Every API is leaky and inconsistent, it's all a matter of degrees.
Concise documentation is essential. I'm reading about a Java API for the 5th time and only now just 'getting it' fairy clearly, it's not rocket science it just needs to be explained properly. Java 'Direct Memory Byte Buffers'. Simple concept, described poorly!
There are three ways you can make an app easy for new developers to quickly be productive in... as long as deployment and code management tools are easy:
* Coaching/Mentoring - Original developers there to help
* Great documentation - App is documented, and it's easy to discover how it's put together
* Great API / abstraction - The api or structure is really easy to understand and use - this is why REST beat out more sophisticated API models. Even so, it needs great documentation to be easy to learn and build with
I think a lot of companies don't get any one of the three above right, so everything is very opaque. Also, you can't let tooling block developers from getting into understanding the code. New dev onboard times are a great way to measure this.
> I see the flow of constructing custom tools during development, and, ideally, for every single development problem, as the next major leap in software development.
I wish I could transmit this concept in my organization.
1) E2E tests as business requirements living documentation are the best first step any organization/project can make besides their tremendous technical value. At least remove the need from contributors to figure out business from code.
2) Confluence-like services cannot work as technical documentation. There's plenty of tools that allow you to generate docs from code, use them!
We should lessen the friction from abstract to development,and that starts with providing good tools that bridge tge two.
The older I get, the more important I think it is to get set up with a simple(ish) development environment where I can easily reproduce bugs, develop features and so on.
This is one area where microservices can be a PITA if the dev environment hasn't had the same attention paid to it that the production environment has.
One place I worked, the rule was "always have two pairs of eyes on code". Each team got to decide whether that rule was met with some mix of mob or pair programming, or just code reviews/pull requests. We could change depending on the needs of the project and team members. If management forces any of these options on teams it is a huge mistake. The point of pair programming is to share knowledge, reduce bugs, etc. and making it into a metric to measure teams by doesn't work.
It's a lot like setting a minimum code coverage rule like 80 or 90%, people end up cursing the rule as it makes them do stupid things to satisfy the rule. Code coverage is one great tool to explore where your code needs more tests, but it's not the only one, and it's not the point. The point is writing code that's easily maintained, safely changed, and can be delivered to meet customer needs.
You hired really smart people (hopefully) and you should let them decide how to work.
This seems like a really, really good justification for the Rails Way of having a sane and predictable app file structure and layout where developers who have never seen your code before can jump in on day one and figure things out very quickly.
Would love to see more web frameworks adopt this opinionated methodology to save us all some time.
It's getting so far from the original web coding I did in 1995 where you had a .html file, to modern frameworks where 99% of the underlying code is in a hidden file nested 17 levels deep that is an interface to a virtual class that exists only in the imagination of the framework creator.
The "Rails Way" doesn't work at all, and in fact hinders understanding, when a new developer doesn't know the Rails conventions. If you're happy to exist and hire within one ecosystem that can be fine. Otherwise it's disastrous.
The alternative is living in a microcosm of your own product/company, as the rest of the world is the wild west with no purported conventions at all. So even if it's a disaster, it's a better disaster than not having recognizable conventions that anyone outside of your company is aware of.
And I say this as someone who originally live-edited PHP sites over FTP on apache in the early 00s. Convention is everything.
Rails can be quite a disaster, but it has some solid conventions on app structure, routing, and security. It's not that Rails is great, it's that having conventions and sane defaults that get you somewhere instead of nowhere is better than not having them. No other major popular framework that I'm aware of has any real conventions on app structure or on any of the core things that 99% of apps need anyway, so everyone is out there re-inventing the wheel.
In most frameworks, you get almost nothing included by default, and have to make key decisions on things like how will you encrypt cookies, how will you do CSRF protection, and sometimes even more basic things like how will you do routing. This has led to rampant security vulnerabilities reminiscent of the PHP days of yore imo. Productivity-wise this has made it impossible to get anything done, because the second you go to work for a new company, you end up having to help them re-implement basic processes like integration testing, CI, app structure, because everyone in the wild is just flying by the seat of their pants and making it up based on their limited experience and knowledge. "Oh, we just copy paste this boiler-plate and manually load SQL files for our migration system" "What's CSRF?" "What do you mean having separate environments for development, testing, staging, and production?" "Oh, we kept getting that CORS error so we just added a wildcard and it went away" etc etc
I almost took a different path for my PhD and made it about capturing the knowledge that went into the creation of software. Can we see what people worked on, what they touched, how it came to be… in conjunction with the things they were also learning/consuming/reading/talking about so that we could bake that into IDEs. Right now we just see text files; the most we have is a git blame but you have to keep pulling the thread. It’s also very hard to traverse across blames in time. I’d rather use past knowledge to both know what’s related to some part, as well as how it came to be to determine where it should go next. I’ve always felt there’s meat on this bone.
The early days of Lighthouse IDE seemed to veer a bit into this by they since diverged.
As someone trying to learn spring boot and lombak to write a complicated service... yeah, this. But I'm not just reading my code, I'm reading abstractions piled on abstractions. It's crazy. In the end I'll have to write less code, but I have to understand so much more just to write that "less code".
Burn lombok with fire. Code you can't read, and cant debug, is horrible to work with.
I find the best was to make your code grokable, is to have junit tests for everything that run fast in the ide. When code needs maintenance, you can run it in the debugger quickly and see what it actually does, instead of what it was intended to do.
The worst Java code is lombok code that gets fsked by aop and/or hibernate. I call these abominations Nojos (not plain old java objects)
Again: burn lombok with fire. Wrong line numbers, ungreppable code, obsure bugs, different depending on the lombok version
70% maintenance cost compared against, two seconds to have your ide automatically make explicit the code you are going to run.
Very true. In fact, this was the impetus behind my project. Over the decades there's been a ton of focus on machine learning and big data, but virtual none on human understanding [of systems].
This matches my experience. IMO the best alternative tovreading code is to talk about the intent of the system by other coders or architects. Formulating questions is a start of understanding. Getting answers or directions increases understanding even more, for both parties.
The idea that “developers spend most of their time in reading and understanding the code” resonated with me, but the tool (gtoolkit) that this article is suggesting is too complex for me to understand and make it work. The tutorials or demos are about an hour long. I would appreciate if any tool can get me started in just 2-3 minutes (max) of hand holding. I don’t want to spend hours in a tool just to get started and then realizing that it will or not work for me.
Unfortunately, gtoolkit has pretty steep learning curve. And it's not different from Pharo gtoolkit is built on.
I think there is a clash of concepts. It took me a lot of time getting used to the smalltalk workflow of experimenting in the playground and jumping into the editor to change things.
It is very different from recompiling and restarting or from running a repl.
I have found that knowing the system is the most important thing over anything else. You end up being less wrong and have fantastic suggestions to the group on the direction and purpose of things or catch those edge cases when something is suggested or comes up that others don't know the consequences of or how it all connects together. This is where true value lies.
I see this perspective too often. The good news is that it does not have to be painful :). Looking inside the system can be beautiful if only we change the tools through which we look.
Yep, once I spent the whole day reading code to write one single line of code at the end of the day. Since my boss is also a developer he understands. Try to explain that to a manager who doesn't write code thou...
For me, this activity is very often driven by "I need to do X, how do I do that?" It can be as general as "I want to make a web app with X language using Y framework". Often (for Golang and python, for example) there are lots of video tutorials talking about the necessary boilerplate -- so much boilerplate.
It can also be extremely specific "I want to split a ReadOnlySpan<char> on some delimiter (which you can't do, you need to cast to a string and use the Split method there). Fortunately, that was an easy thing to find an answer for.
Sometimes I want something specific that I have no clue how I would even start looking for the answer. I want to build a web app with a modular payment end-point so I can plug/play a large number of providers (ideally, I'd be able to arbitrarily hook in Stripe or the Bitcoin Lightning network or something else entirely). There are a host of problems for me here; I don't understand the problem space, so I have no clue what a "good" solution would look like, I don't even know if generic payment APIs even exist (zero research on my part), let alone in languages I understand (go, python, C#).
I guess my issue is formulating questions appropriately, so that the sum of answers is an answer to my driving question "how do I do X?"
As a non-developer, this strikes me as funny. Like when Uber “invented” the bus.
People who have knowledge-worker jobs and are halfway decent at them spend a lot of their time planning and making sense out of the systems they work in.
Believe it or not, the oft-derided-on-HN MBAs and marketing people figure things out, too!
Consider how the marketing work changed over the past decade to integrate data science. The amount of time spent on decision making might have not changed, but how the time is spent did change significantly.
The article argues that the same thing should happen in software: developers should spend less time gathering information through data science and more time making decisions. This happens to change the nature of programming.
For an environment that's supposed to be about making things easier to discover, the glamorous toolkit website is pretty useless. Lots of bragging about how great it as, and lots of unreadable screenshots that do not interest me enough to actually download and install the thing.
The environment aims to make systems easier to grasp for people that want to explore their inside. This is quite different from the marketing challenge of convincing one to download a tool after a few seconds :).
If this was say, an optimizing compiler, I wouldn't worry that much about their pitch.
The tool is (from what little I could glean) supposed to make discoverability better. That suggests to me that they know something about how to make things discoverable, by bubbling up important information, hinting at where you want to go. The website was pretty much NOT that. Sure, maybe it's one of those "the shoemaker has the worst shoes" things. I'm interested, but not interested enough to work hard at figuring out what the thing is even supposed to to. If I want to work hard to explore the inside of a system, I can already do that.
More on topic, I've experimented some with Glamorous Toolkit, and I really liked what I saw of it, but (somewhat ironically), I need to dive more into its own model and understand it before I can use it for anything real.
For example, I couldn't find docs on its display stack, so when I wanted to display a graph but with images instead of text for the nodes, I got stuck. Sure, I could dive into the code and eventually get something that worked, but I wouldn't be sure I was coding to the API or to the implementation. It crossed over to "playing around with this tool" to "have to do some real work to understand", so I ended up dropping it.
I understand that it can feel uncomfortable to look into a system to know how to use it. However, Glamorous Toolkit is the first large case study of moldable development.
To this end, there are custom little tools inside (some ~2k of them) that help you in this exploration. For example, one of the first things we encourage people to learn when they start with GT is how to query the GT code from within GT.
Indeed, we are still to improve the onboarding experience. To this end, more recently, we added a book with live explanations. This is still a work in progress.
That said, GT should be approached as a language. One can do as much with basic hello world exercises, but to extract more value one has to go into deeper details.
Question though: what about very stable codebases that are actively developed for a long time. My team maintains a couple SW projects (for internal manufacturing and equipment automation) with a core that has been stable for 10+ years. Once a developer is up to speed (3-6 months) that cost is recouped over several years.
Of course this doesn't work for projects utilizing brand-new technology but it doesn't make sense to throw all types of projects into one pot. If there's a case to be made that mature code bases require less "figuring out time" then organizations should discourage jumping on the latest technology "just because".
Interesting. We find the situation to be quite the opposite. The older and larger the system, the more expensive figuring out is.
You mention a 3-6 months. That's quite a high price. Would it be inconceivable to optimize this significantly?
Stability can also be misleading. It's especially the small changes that can be problematic because when the code is large enough, people simply do not know what of what they already know (what's already in their memory) is no longer true. This is the challenge. Instead, the proposition is that we should not have to rely on our memory of things that can change. We can just check it. Only to do it in a reasonable timeframe, we need custom automation.
In any case, the article does not propose a tool. It proposes a way of working. The tool is important to show how it can work in practice.
The creation of tools can actually be minutes cheap. Through Moldable Development one creates such tools regularly, and most of these are thrown away after being used just once. That can sound like a waste, but it's a significant booster. It does require new skills though.
We're being paid to do the work necessary to meet the goals set by management, and to provide useful feedback and guidance about what is/isn't possible, and how long it will take.
If they (management) choose to ignore our guidance, or straddle us with bad tools, it sucks for us, and them, and the company.
Parkour is a way to enter a building but if you expect other people to do it too, you’re off your gourd. If you insist on everyone else doing it, you’re a maniac.
Most of the time i feel i watch and learn new things, try to work with them, fail on some point, cause the new shiny things are not so shiny and easy as it seems. "The devil is in the details".
Read article about how great these tools and libs are, how "easy", how they save so much time. Thinking about what i am doing wrong. Illusion. Self-deception.
Try 1000 other libs and tools and frameworks and and and, repeat in an endless loop.
My real productiv code is absolutly tiny compared to the huge amount of work i have and how much a permanently learn and educate myself.
I 100% agree with this. I would say that 99% of time is spent figuring the system out, and most maintenance time or new features time is just figuring out what is already going on.
Developing is constant problem solving. Inside the app domain and also outside. Nothing new here. Someone claiming developing is possible only within the app domain is a fool.
Which is why as a code reviewer the legibility of the system is my top priority. I don't even care if the code works that'll come out in testing. I care if I can look at each section and understand what it's doing and why.
And I'm utterly flabbergasted how many developers don't understand this.
Legibility is relevant. The problem is that legibility requires one to read. And one cannot read the whole code fast enough. That's why legibility is relevant in the small (~one screen). In the large, we can benefit greatly from other ways to summarize the system.
Regarding pair programming - I'm a self-taught freelancer based in a remote area (not many local devs). How might I bring about the benefits of pair-programming or even mentorship in a remote context? Mentor As A Service? Sounds a little lame to be honest.
Dang - from the way the article was written, I was really hoping to see some magic static code analyzer that would explain a system to a developer. But instead it looks like some enhanced version of Jupyter notebooks?
The proposition is not a tool, but an approach (moldable development). In a way, it is like data science, but for software. The approach was validated for more than a decade in industrial settings. Indeed, there is an environment involved to show how it can work in practice. It's understandable that one can see it as some kind of notebook, but it's really more than that. For example, there is a lot of emphasis on custom inspectors as basic pieces in the environment.
Not quite. It's a motivational text for Moldable Development (https://moldabledevelopment.com). This is a way of programming through which programmers construct custom experiences for every single development problem. This is a significant departure from the typical development flow today, and Glamorous Toolkit is merely the arena in which to explore what is possible when thinking like this.
As a past customer, this is simply a great company with many Greenfields ahead in the space and some of the best leadership I've crossed in the Valley.
This only has an impact when we want to change a system. Coincidentally, the majority of our work is changing a system through addition of new functionality or maintenance.
I've thought about this problem for a long time. The conclusion I've come to is that it happens because the code doesn't look like the domain. Domain language is often missing in the code the engineers are working with so when new changes are requested the engineer needs to translate between the domain language and the language the code is using. I work in an object oriented language so my perspective is as follows:
Ideally, all that should be required is a correct domain understanding. If the objects in the code reflect the domain as understood and explained by the people giving the requirements then the engineer's job becomes easier. Instead of solving 2 problems, translation and engineering, they only need to focus on engineering.
For example, imagine a payment system. A requirement comes in stating that the way a credit transaction in a payment is processed has changed. The transaction should now be processed by doing x, y, and z instead of a, b, and c. The engineer should be able to find an object in the code called a payment that has a credit transaction object with a method named process. Once they find this with a simple text search they know exactly where their change needs to happen. They should then see a, b, and c happening as explained in the domain language. Once this is identified the change can be performed.
In reality, we seldom find domain objects with domain behavior in our code. What we find are Processor and Controller and Handler classes that have nothing to do with the domain. The behavior or data that we need to change is spread among multiple of these classes whose connection was arbitrarily decided by another engineer at a previous point. The new engineer has to work twice as hard to understand what decisions the previous engineer made to represent the domain.
It's much easier at first to do this translation work because we don't want to, or have time to, understand the domain. But business domain experts are experts for a reason. They know how to solve business problems within their domain. We are not domain experts. So we end up reinventing the domain solution wheel when we do things this way. We end up solving the business problems and the engineering problems.
Instead, we should see ourselves as modelers. Remember that computer science arose as a sub field of physics. The main purpose of physics is to develop models that represent the real world and solve problems using those models. Our job as software engineers is to model the domain and solve problems using those models. Our job is not to translate requirements into technical solutions. Nor is it to solve business problems.
I very much concur with the view of programming being a projection of our understanding of something in the world (physical or otherwise) into executable code. Like you point out, much can be improved by eliminating the unnecessary dissonance between implementation and domain.
However, we can still do much more than that. Take your example of searching textually for a class / method. First, when we search by text we assume that code has no structure. Would it not be a significant optimization to have a search that allows you to be search semantically through your system?
Now, the problem is that a system is interesting from many different perspectives.
- For example, a security issue is most likely going to be crosscutting the domain. When we look for it, we would like to see a projection of the system specifically for our problem.
- Or take communicating with the domain specialists. Most often, that communication happens on the whiteboard. However, what is manually drawn on the whiteboard represents what the writer thinks, not necessarily what the system is. To see the system, we should want the system to draw itself on the whiteboard. Any manual intervention in this process introduces an interpretation that hinders the communication. So, we can start with writing on the whiteboard when the system does not exist, but as soon as it does exist, we should have the system draw its representation. That can enhance communication manyfold.
I have empirically determined that the main reason for this problem is the unwillingness to put in the effort to completely automate the work. The most often used argument I get is:
it's not worth the effort to completely automate something that one has to perform maybe only once in six months or once per year.
This argument is patently flawed and wrong, because it assumes that it's only worth automating something if it is done often enough. Scientifically, "often enough" isn't quantifiable, and that argument completely neglects the repeatability aspect: by fully automating, the steps to perform something are codified and quantified.
